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
