Because the scalar context is applied before the sub returns. In a scalar context, 'return' only pushes one scalar onto the stack. (The section you quoted is describing what happens for for(fun()), which isn't a scalar context.)
I have to admit. One can imagine that opcode for "return" looks up the context and returns on the stack only what context desires. It could be done this way. But if you check "perldoc perlxs" section "Returning SVs, AVs and HVs through RETVAL", then you'll see, that the extension functions don't need to check the context. They can simply place the AV (array) or HV (hash) on the stack, and the caller will do the context adjustment for them.
Well, one can still imagine, that the pure perl functions and the extension functions use different stack discipline, but somehow I find it unlikely.
At the end of the day. For the perl programmer it does not make any difference how the internal perl stack is managed. The main point is, returning an array from function produces different results than returning a list. This is the message I was trying to convey.
By the way. Have you ever tried
Here, the array IS returned from the function :)use strict; my @a; sub canmod : lvalue { @a; } (canmod()) = qw(c d e); print join(',', @a), "\n"; print join(',', canmod()), "\n";
In reply to Re^10: Confused as to why the "casting context" is mis-behaving (clinging)
by andal
in thread Confused as to why the "casting context" is mis-behaving
by kiz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |