>>>>> "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

Reply via email to