in reply to Re^6: Getting an unknown error
in thread Getting an unknown error

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

Replies are listed 'Best First'.
Re^8: Getting an unknown error
by AnomalousMonk (Archbishop) on Apr 24, 2015 at 15:40 UTC

      I gather that the point in your Re^8: Getting an unknown error (foreach $1 breaks m//atch) is that "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."

      OK; I agree with that, but I've found nothing, nor have you cited anything, that says or suggests it's "weird" to use $n as an iterator. A very succinct clarification is possible: "(I)t's possible, but unwise, to use $n as an iterator."

      Think of the frequency with which the perlvar warns "See Performance issues...." or, more generally, that perldocs take the space to observe something on the order of Such-and-such a use of (function) produces undefined results. The cost of this clarification is trivial.