Revert "document that sigs in future may not populate @_"

This reverts commit 19d6c3854e96d89bf4dc2d874df433beac27ee8b.

2 files changed, 3 insertions, 12 deletions

diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index f18a696c77..72f9890e41 100644
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -296,13 +296,6 @@ breaking existing code.  To avoid this a future version of perl will
 throw an exception when any of C<sysread()>, C<recv()>, C<syswrite()> or C<send()>
 are called on handle with the C<:utf8> layer.
 
-=head2 Signatured subs should not rely on @_
-
-Currently the experimental subroutine signature facility still populates
-C<@_> in addition to setting the parameter variables. In the next major
-release of perl this is likely to change, so that C<@_> is not populated by
-default (although a new mechanism will be provided to re-enable it).
-
 =head1 Performance Enhancements
 
 =over 4
diff --git a/pod/perlsub.pod b/pod/perlsub.pod
index a7b9bf3642..78de284733 100644
--- a/pod/perlsub.pod
+++ b/pod/perlsub.pod
@@ -458,11 +458,9 @@ that the caller passed no arguments:
 	return 123;
     }
 
-When using a signature, the arguments are currently still available in the
-special array variable C<@_>, in addition to the lexical variables of the
-signature, but in a future release of perl that may change to being not
-available by default. There is a difference between the two ways of
-accessing the
+When using a signature, the arguments are still available in the special
+array variable C<@_>, in addition to the lexical variables of the
+signature.  There is a difference between the two ways of accessing the
 arguments: C<@_> I<aliases> the arguments, but the signature variables
 get I<copies> of the arguments.  So writing to a signature variable
 only changes that variable, and has no effect on the caller's variables,