<div class="gmail_quote">On 13 March 2012 18:07, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 3/13/12 10:48 AM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
float t;<br>
...<br>
(myStruct.pos, t, _, int err) = intersectThings();<br>
</blockquote>
<br></div>
I actually find the scatter syntax better than this. Anyway, I hope you'll agree there's not much difference pragmatically.</blockquote><div></div></div><br><div>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.</div>
<div><br></div><div>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. Maths-y code should be un-cluttered and read sequentially. Having to put extra lines in to munge un-related things really ruins the code IMO ('t' is of no consequence to the user, pollutes their namespace, gets in the way with extra lines, etc).</div>
<div>What people want from MRV is to capture the returned values independently. If I <i>wanted</i> to capture the returned Tuple (the extremely rare case), I'd rather do that explicitly, something like this:</div><div>
auto t = tuple(mrvFunc());</div><div><br></div><div>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...</div><div>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 <i>inefficient</i> 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.</div>