document that sigs in future may not populate @_

Give people a heads up that in the next major perl release, subroutine
signatures may no longer populate @_ by default.

See http://nntp.perl.org/group/perl.perl5.porters/235332.

diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index 16c7e89..ef1cc4d 100644 (file)
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -296,6 +296,13 @@ 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 78de284..a7b9bf3 100644 (file)
--- a/pod/perlsub.pod
+++ b/pod/perlsub.pod
@@ -458,9 +458,11 @@ that the caller passed no arguments:
        return 123;
     }
 
-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
+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
 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,