These variables are read-only ...

I suspect that statement can be found at least back to 5.10 and maybe to 5.8.

I checked my local perlvar for the versions I have in captivity, 5.8-14, and this assertion is in each one. (I didn't bother to check all the on-line perlvar versions; I assume it's in all those as well.)

For all my initial shock at seeing an old, dear friend abused in this way, I'm not so sure | I do not think it's classifiable as a bug. After all,  $1 is just a symbol, and aliasing is supposed to enable one to treat one symbol exactly like another. That's what's going on in the for-loop: the perfectly mutable  @line array elements are successively aliased to the  $1 symbol, to which one can do anything it's kosher to do to an element of the array. One can see this here:

c:\@Work\Perl>perl -wMstrict -le
"my @lines = (qq{foo\n}, qq{bar\n});
 print qq{[[@lines]]};
 ;;
 for $1 (@lines) {
   chomp $1;
   print qq{'$1'};
   }
 ;;
 print qq{[[@lines]]};
"
[[foo
 bar
]]
'foo'
'bar'
[[foo bar]]
[download]

c:\@Work\Perl>perl -wMstrict -le
"my @lines = (qq{foo\n}, qq{bar\n});
 ;;
 for my $ln (@lines) {
   $1 = $ln;
   chomp $1;
   print qq{'$1'};
   }
"
Modification of a read-only value attempted at -e line 1.
[download]

Update: See "alias" in perlglossary.

Good info. Thanks. In view of that, my second suggestion for action: correction of the docs still seems to be in order, since the current statement is unambiguously incomplete or therefore, inaccurate|incorrect. Maybe, at minimum, an addition to the existing language (to the effect that use involving aliasing is an exception to the "read only") would be in order.

Thanks to your research, I share the view that there's no reason to tamper with the extant code, but see the current language in perlvar as a "bug in the documentation."



Quis custodiet ipsos custodes. Juvenal, Satires


And... check Ln42!

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.

---

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