I ... see the current language in perlvar as a "bug in the documentation."

I must disagree that it's a documentation bug. A symbol like  $1 is just a name slapped on underlying data. It's a convenience. The underlying data may have special properties, like immutability in the case of the  $1 capture group variable. There are many special and "magical" variables in Perl. If the previously defined name of a variable is "aliased away" to another variable, the special properties of the original variable don't go with it. That's a feature of aliasing and must be understood as such. To be consistent, the documentation would have to say, for every Perl variable with any special property, that the special property will not transfer to another variable if the variable's original symbolic name is aliased to the other variable.

I must admit that the extremely idiosyncratic use in the OP of  $1 as a for-loop variable had me going for a bit. I think it's syntactically correct, however, and likewise the docs, and any problem lies with the OPer's understanding and use of the language.

Wow, what amazing discovery, somebody should perlbug this in a hurry

The bug is that it breaks $1 and m//atching operator, and it doesn't warn...

$ perl -wle " $_ = 333; for $1 ( 666 ){  print $1 if /(...)/;  }"
666

$ perl -wle " $_ = 333; for $1 ( 666 ){  local our $1; print $1 if /(.
+..)/;  }"
Use of uninitialized value $1 in print at -e line 1.
[download]

No warnings are issued, matching is broken in a different scope, its a bug ... kind of amazing people don't trip on it every day

Kinda related
Lexical $_ in given/when vs. BLOCK arguments
 Bug #115834 for perl5: Successfull match $_[0] =~ /foo(.+)/ overrides $_[0] if function called as foo($1)

... it breaks $1 and m//atching operator ... No warnings are issued, matching is broken in a different scope ...

It certainly aliases  $1 and this is certainly not a good idea, but matching is not broken. (Please see example code below.) A match is made properly and the truth of the match is returned. The content of capture group 1 cannot be directly accessed (because the  $1 symbol has been aliased to something else), but the content of this group is still proper and can be accessed indirectly if a kind of "preemptive strike" aliasing of  $1 (or rather of the data it symbolizes) has been done. Other variables associated with this group still function as expected. I don't see your point about matching in a different scope (which I take to mean outside the scope of the for-loop alias) being broken; again, see code below. As to warnings... well, as weird as this (ab)use of  $1 is, in programmng as in life, it's just not possible to warn about all the weird things one might do; at some point one must fall back upon common sense.

c:\@Work\Perl\monks>perl -wMstrict -le
"for my $one ($1) {
   $_ = 'xx333333xx';
   for $1 (666) {
     print qq{A: '$one' $-[1] $+[1]  '$2'} if /(333)\1(xx)/;
     print qq{\$1 '$1'};
     }
   }
 ;;
 print qq{B: '$1' $-[1] $+[1]  '$2'} if /(\d\d\d)\1(\D\D)/;
"
A: '333' 2 5  'xx'
$1 '666'
B: '333' 2 5  'xx'
[download]

Bottom line: This is just the way aliasing works (insofar as I understand it), but you don't have to use something just because it works. Again, common sense.

---

Give a man a fish:  <%-(-(-(-<

Re Re^7: Getting an unknown error (foreach $1 breaks m//atch) by an Anonymous Monk: perldoc perlvar again...

$_ is by default a global variable. However, as of perl v5.10.0, you can use a lexical version of $_ by declaring it in a file or in a block with my. Moreover, declaring our $_ restores the global $_ in the current scope. Though this seemed like a good idea at the time it was introduced, lexical $_ actually causes more problems than it solves. If you call a function that expects to be passed information via $_ , it may or may not work, depending on how the function is written, there not being any easy way to solve this. Just avoid lexical $_ , unless you are feeling particularly masochistic.



Spirit of the Monastery

Tracking which node responds to which is getting a little twitchy, so, to be clear, this was written (before the thread got so complicated) in response to Re^6: Getting an unknown error.

----END UPDATE of 2015-04-25----

Excellent discussion, AnomalousMonk, for which, ++.

BUT, it falls short of persuading me: I hew to the notion that docs at the perldoc docname level of authority should accept a (small!) bit of verbosity to handle significant exceptions... or perhaps rephrase to avoid making (what I see as) a manifestly false statement; one which is NOT clarified nor constrained by its context.

In this case, I would argue that it is [ inaccurate | misleading | false ] to state categorically and without qualification (as does perlvar):

These variables are read-only and dynamically-scoped.

I acknowledge a possible reason for believing otherwise than I do... that the context is discussion of the $n variables as used in regexen (under the subhead, "Variables related to regular expressions)."

But, I don't think even that is adequate justification for phrasing that appears to be at the root of an widely-held but inaccurate mime.

Perhaps the doc editors [ could | should ] revise the perlvar statement by adding the word "generally" and extend it by noting that $n can -- BUT SHOULD NOT - be used as an iterator (that may not be sufficiently broad, but I hope it suggests an approach. I find NO caveat on that point in the perldoc .... collection.

Of course, maybe someone will correct me, and find a limiting counterstatement in authoritative documentation; other than the content of this thread) but




Spirit of the Monastery

Please see the points relevant to warnings in my Re^8: Getting an unknown error (foreach $1 breaks m//atch) reply above.

---

Give a man a fish:  <%-(-(-(-<