>>>>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> I don't want that to change. I simply want that return (I'm not sure
>> how to phrase this) be able to return only a scalar or an aggregate.
TC> die unless wantarray;
Okay, I'll admit it, again. I find the changing of a comma in what
looks like a list changing into a comma operator because of a caller
several thousand lines away disconcerting.
>> It should be immune from having a scalar context pushed through from
>> the caller and change the commas from a list seperator into the comma
>> operator.
TC> Ok, how are you going to jam a list into a place that only
TC> holds a single thing? Modulo some superpositional silliness,
TC> you aren't. You need a rule for what to do. We have a rule
TC> for that, but you don't like it. It's not sensible that this
TC> rule be applied inconsistently.
I don't want to jam a list into anything. I want it to remain a list.
sub fn { return (3,5,7) }
$x = fn; # I want $x==3
I want to lose the conversion of the ',' into a comma operator when
it is in a return.
-internals is hoping that pushing a single aggregate on the stack
rather than flattening would be a win.
So it might effect the following,
(@foo, @bar) = (@bar, @foo); # exchange
(@foo, $x) = (@bar, (3,5,7)); # $x = 3
The entire thing is in a list context, but the $x imposes a scalar
context on the 'list' at the end. (To keep something of backward
compatablity, it probably would need to act differently if the @
is not in the final position.)
Now here is where it would probably break, and give you a fit trying to
explain it.
($x) = (getpwnam($name)) # $x = $name
(@foo, $x) = (&fn, getpwnam($name)) # $x = $>
*sigh*
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
