Multiple return values...

[Manu]

On 13 March 2012 19:25, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> On 3/13/12 12:02 PM, Manu wrote:
>
>> There's a few finicky differences. I'm still of the understanding (and I
>> may be wrong, still mystified by some of D's more complicated template
>> syntax) that once you give the returned tuple a name, it is structurally
>> bound to the stack. At that point, passing any member by-ref to any
>> function must conservatively commit the entire tuple to the stack. This
>> behaviour won't be intuitive to most users, and can be easily avoided;
>> by obscuring the Tuple from user visibility, they can only access the
>> returned values through their independant output assignments, which
>> guarantees the independence of each returned item.
>>
>
> Here we go moving the goalposts again.


I don't see how? I'm just saying that I don't think they are pragmatically
identical.

Syntactically, scatter can't declare new variables inline (?), it also
>> uses additional lines of code (1 + as many variables as you need to
>> declare), which is very disruptive to flow.
>>
>
> This is in addition to Kenji's change.
>

What value does it add over Kenji's change? Is this because Kenji's change
is unable to perform direct to existing variables?
My understanding from early in the thread was that Kenji's change hides the
returned tuple, and performs a convenient unpack. How can you perform a
scatter if the tuple instance is no longer visible?

What people want from MRV is to capture the returned
>> values independently. If I /wanted/ to capture the returned Tuple (the
>>
>> extremely rare case), I'd rather do that explicitly, something like this:
>> auto t = tuple(mrvFunc());
>>
>
> No. Tuple stays together by default and is expanded explicitly. This is
> not negotiable.
>

Then I think you commit to polluting the common case with wordy redundant
noise. Why is it so important?
If it were expanded by default, all you need to do it put a tuple
constructor around it to wrap it up again.
It creates semantic multi-assignment problems I suspect? This is what I
reckon needs to be addressed to make the implementation really nice.

scatter/gather is nice and simple, I'll take it in the mean time, but I
>> think it would be a shame for it to stop there longer term...
>> That said though, it's all still nothing to me without at least a
>> promise on the ABI :) .. And I feel that should ideally come in the form
>> of a language policy/promise that this feature will be 'efficient' (or
>> at very least, not /inefficient/ as it is now), and leave it to compiler
>>
>> implementations to concur with that promise, ie, failing to be
>> 'standards' compliant if they fail to do so.
>>
>
> This is not for me to promise.


Sure, but it'd be good to get a weigh in on that issue from Walter, and
others, Iain?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120313/59a0a44d/attachment-0001.html>