|more useful options|
Re^4: Why does the first $c evaluate to the incremented value in [$c, $c += $_] ? ("undefined")by tye (Sage)
|on Mar 05, 2014 at 16:49 UTC||Need Help??|
But why [is aliasing] also involved when composing a list?
Most likely because a list can be used like:
But I'm just guessing. There are usually some subtle implementation details involved. There is often quite complicated history involved as well.
Where is documented?
The types of things that are more likely to change based on changes to Perl having to do with esoteric implementation details, especially optimizations, are often bad things to try to document, IMHO. In any case, I doubt this is documented.
Modifying a variable in the same statement where you use the variable is just something to avoid. Knowing what it does in this version of Perl doesn't mean it will continue to do that in another version of Perl. Having a rough understanding of why it does what it currently does, tends to not be very reliable in allowing even a rather gifted Perl programmer to avoid getting rather different behavior from a very similar construct (and thus being surprised and perhaps resulting in a bug in the code being written).
C is nice in having a standard that pretty clearly lays out this type of thing as officially "undefined behavior". This is a very useful way to push back against clever programers' natural tendency to, from time to time, want to continue to use some overly clever construct.
That C rule and definition don't really apply to Perl. But the motivation for them very much applies to this type of thing in Perl. Trying to tie down exactly how something like this should behave just leads to complex and problematic tying of the hands of the implementers and fixers of bugs in Perl.
So just don't do this type of thing. And don't get too obsessed about why it does what it does. It is more important to understand why it is a construct that you shouldn't be writing. If you've got that down, then you can casually try to better understand what is going on in an attempt to better understand some aspects of Perl. But beware that this might put you at risk of, perhaps unintentionally, relying upon these new assumptions. Best to keep such conclusions you come to marked as guesses or at least vague and not something to rely upon.