Multiple return values...

[Andrei Alexandrescu]

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.

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

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


Andrei