<div class="gmail_quote">On 13 March 2012 19:25, 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 12:02 PM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There's a few finicky differences. I'm still of the understanding (and I<br>
may be wrong, still mystified by some of D's more complicated template<br>
syntax) that once you give the returned tuple a name, it is structurally<br>
bound to the stack. At that point, passing any member by-ref to any<br>
function must conservatively commit the entire tuple to the stack. This<br>
behaviour won't be intuitive to most users, and can be easily avoided;<br>
by obscuring the Tuple from user visibility, they can only access the<br>
returned values through their independant output assignments, which<br>
guarantees the independence of each returned item.<br>
</blockquote>
<br></div>
Here we go moving the goalposts again.</blockquote><div><br></div><div>I don't see how? I'm just saying that I don't think they are pragmatically identical.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Syntactically, scatter can't declare new variables inline (?), it also<br>
uses additional lines of code (1 + as many variables as you need to<br>
declare), which is very disruptive to flow.<br>
</blockquote>
<br></div>
This is in addition to Kenji's change.<br></blockquote><div><br></div><div>What value does it add over Kenji's change? Is this because Kenji's change is unable to perform direct to existing variables?</div><div>
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?</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">What people want from MRV is to capture the returned<br>
</div>
values independently. If I /wanted/ to capture the returned Tuple (the<div class="im"><br>
extremely rare case), I'd rather do that explicitly, something like this:<br>
auto t = tuple(mrvFunc());<br>
</div></blockquote>
<br>
No. Tuple stays together by default and is expanded explicitly. This is not negotiable.<br></blockquote><div><br></div><div>Then I think you commit to polluting the common case with wordy redundant noise. Why is it so important?</div>
<div>If it were expanded by default, all you need to do it put a tuple constructor around it to wrap it up again.</div><div>It creates semantic multi-assignment problems I suspect? This is what I reckon needs to be addressed to make the implementation really nice.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
scatter/gather is nice and simple, I'll take it in the mean time, but I<br>
think it would be a shame for it to stop there longer term...<br>
That said though, it's all still nothing to me without at least a<br>
promise on the ABI :) .. And I feel that should ideally come in the form<br>
of a language policy/promise that this feature will be 'efficient' (or<br></div>
at very least, not /inefficient/ as it is now), and leave it to compiler<div class="im"><br>
implementations to concur with that promise, ie, failing to be<br>
'standards' compliant if they fail to do so.<br>
</div></blockquote>
<br>
This is not for me to promise.</blockquote><div><br></div><div>Sure, but it'd be good to get a weigh in on that issue from Walter, and others, Iain?</div></div>