The way context is propagated to the return statement (resp. the last statement) of a sub is indeed a problem.
( its too surprising how return 1..3 behaves and suddenly transforms into a flip flop)
That's why subs were remodeled in Perl 6 and I'd really appreciate a similar feature or pragma switch in Perl 5.
Regarding your list() routine, I think it solves the wrong problem . The behavior of comma separated lists comes from the "scalar comma operator" and is rarely useful.
The IMHO "most normal behavior" is to return a count, like arrays do. This fits perfectly into boolean context! That's why I occasionally wrap my values into a @{[...]} construct.
But that's too short to justify an own built-in function.
Maybe something like arr() could at least add some more readability.
YMMV! :)
To complete the picture, I was also in situations where I would have preferred $a=call() to act like:
Tastes differ, IMHO its rather a question of clear notation.
And wantarray is not only a misnomer, but too difficult handle in 3 contexts. Damien published a module handling this which should better be XSed and Core.
Cheers Rolf
(addicted to the Perl Programming Language)
In reply to Re: There's scalar(), but no list(). Perl could need one for rare but reasonable use
by LanX
in thread There's scalar(), but no list(). Perl could need one for rare but reasonable use
by flowdy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |