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."

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:  <%-(-(-(-<

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)

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