|Do you know where your variables are?|
Comment onby gods
|on Feb 11, 2000 at 00:06 UTC||Need Help??|
This is documented in perldata, though maybe not as clearly or concisely as one might hope.
The first issue is whether a slice is a list or not, ruling out the possibility that it is an array.
This isn't stated clearly, as one might hope, in Slices. In that section it is, at best, only hinted at by statements like:
A slice accesses several elements of a list, an array, or a hash simultaneously using a list of subscripts. Itís more convenient than writing out the individual elements as a list of separate scalar values.
Since you can assign to a list of variables, you can also assign to an array or hash slice.
Perhaps the closest this section comes is:
But this only states the exact equivalence in the case of assignment to a slice. It doesn't state that there is an exact equivalence in all cases.
There are other indications. In Context one finds (emphasis mine):
or slice, which is just a list anyway)
And in Variable names one finds:
So, perldata does not clearly, concisely and definitively state that slices and lists are equivalent in the obvious place (Slices), but none the less,if one reads carefully, I think this is the conclusion one would come to.
If one accepts that a slice is equivalent to a list, then this leaves the question of what a list evaluates to in scalar context.
In Scalar values one finds (emphasis mine):
If you evaluate an array in scalar context, it returns the length of the array. (Note that this is not true of lists, which return the last value, like the C comma operator, nor of built-in functions, which return whatever they feel like returning.)
The Note about lists is equivalent to the statement: If you evaluate a list in scalar context, it returns the last value, like the C comma operator.
Thus we have the two relevant facts documented, more or less:
These together predict the observed behavior.
The quote from perltrap is interesting but I don't find it inconsistent with any of the above. It really should be covered under Context. They take care to state the context of the righthand side in the case of assignment to a list, but don't cover this less obvious case.
In reply to Re^3: Confused as to why the "casting context" is mis-behaving