Mention in more places that my $_ is deprecated
authorFather Chrysostomos <sprout@cpan.org>
Tue, 4 Dec 2012 18:44:08 +0000 (10:44 -0800)
committerFather Chrysostomos <sprout@cpan.org>
Tue, 4 Dec 2012 18:51:22 +0000 (10:51 -0800)
pod/perlfunc.pod
pod/perlsyn.pod

index 6a7dcdb..f39974e 100644 (file)
@@ -2968,7 +2968,8 @@ or another C<grep>) actually modifies the element in the original list.
 This is usually something to be avoided when writing clear code.
 
 If C<$_> is lexical in the scope where the C<grep> appears (because it has
-been declared with C<my $_>) then, in addition to being locally aliased to
+been declared with the deprecated C<my $_> construct)
+then, in addition to being locally aliased to
 the list elements, C<$_> keeps being lexical inside the block; i.e., it
 can't be seen from the outside, avoiding any potential side-effects.
 
@@ -3613,7 +3614,8 @@ most cases.  See also L</grep> for an array composed of those items of
 the original list for which the BLOCK or EXPR evaluates to true.
 
 If C<$_> is lexical in the scope where the C<map> appears (because it has
-been declared with C<my $_>), then, in addition to being locally aliased to
+been declared with the deprecated C<my $_> construct),
+then, in addition to being locally aliased to
 the list elements, C<$_> keeps being lexical inside the block; that is, it
 can't be seen from the outside, avoiding any potential side-effects.
 
index fe473f6..0d8fd0d 100644 (file)
@@ -651,7 +651,9 @@ dynamically scoped alias to the original, as it would be if it were a
 C<foreach> or under both the original and the current Perl 6 language
 specification.  This bug was fixed in Perl
 5.18.  If you really want a lexical C<$_>,
-specify that explicitly:
+specify that explicitly, but note that C<my $_>
+is now deprecated and will warn unless warnings
+have been disabled:
 
     given(my $_ = EXPR) { ... }