> $\ = "\n"; print $a = () = qw(a b c);
>-->
> 3
>All those who expected that the list would be evaluated in array (not
>list!) context, raise your hands. Not many, I would think.
What the devil is "array context"? You mean the thing that push expects
for its first argument? Just what were you really expecting here?
You have merely illustrated an example of the following well-known
and long-documented property:
% man perldata
List assignment in a scalar context returns the number of
elements produced by the expression on the right side of
the assignment:
$x = (($foo,$bar) = (3,2,1)); # set $x to 3, not 2
$x = (($foo,$bar) = f()); # set $x to f()'s return count
This is very handy when you want to do a list assignment
in a Boolean context, because most list functions return a
null list when finished, which when assigned produces a 0,
which is interpreted as FALSE.
People crying for a way to force something to run in list context
haven't thought this through. It will already *be* in list context,
so nothing is needed. Or, if it is *not* in list context, than it's
in scalar context, so you need to choose a rule for handling a list
in scalar context.
If you evaluate a named array in a 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.)
This amounts to nothing but an obfuscatory approach to running
(...)[-1] on an exceedingly rare cases: call it that, then. Or,
if you want to make it be the element count, then you should call
it *that*. But this call to make a listificating coercer is not
well thought out; there are serious ramifications that lead one
quickly into discarding the whole thing as a hobgoblin of foolish
inconsistencies.
I've written this all up. And I've mailed it.
--tom
