<div class="gmail_quote">On 11 March 2012 05:04, 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/10/12 4:37 AM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I still fundamentally see a clear divide between a Tuple, which is a<br>
deliberately structured association of multiple values, and 'multiple<br>
return values' which is an explicit non-association of multiple returned<br>
things.<br>
</blockquote>
<br></div>
There is no difference. A Tuple is a product type, exactly like superposing arbitrary values together.</blockquote><div><br></div><div>So you're saying that whatever I think about the implementation of Tuple is wrong? It is not actually a structured type?</div>
<div> </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">
You need to address that principle before I can begin to accept the idea<br>
of abusing a structured tuple as a substitute for this important<br>
language feature.<br>
<br>
My analogy is the function argument list. You don't think of the<br>
arguments you pass to a function as a Tuple (is it implemented<br>
internally in this way? if so, it is well hidden, and perhaps similar<br>
magic can be done...)<br>
You pass, TO a function, multiple un-associated values.<br>
</blockquote>
<br></div>
This analogy is tenuous for D because functions are defined to return one type, e.g. typeof(fun(args)) is defined. Once we get into disallowing that for certain functions, we're looking at major language changes for little benefit.</blockquote>
<div><br></div><div>I don't know how 'major' they'd really work out to be. It's not a paradigm buster. There are some details, but I don't even think it would need to be a breaking change to the language (maybe some very subtle tweaks).</div>
<div>Can you quantify 'little' benefit? I started this thread because I have found myself wishing for this feature every other day. It would be of huge value, and many others seem to agree.</div><div><br></div><div>
D has it all, there are so many features in D which make it feel like a modern language, but this is a missed(/rejected?) opportunity. It's a natural thing to want to ask a computer to do, but we're mentally trained into the returns-a-single-thing model from C and whatever and apparently it was never considered at the initial design stage, but apart from the expressive side, more importantly in D's case as a native language, it is an opportunity to implement an important low level feature that no other language offers me; an efficient multi-return syntax+ABI.</div>
<div><br></div><div>In the tight loops of every program I've ever written, I can't recall a time when I haven't had a function that needs to return multiple things, and C/C++ has always forced me into unnecessary memory access to express this (ref parameters). For the first time in language/compiler history, D would finally be able to eliminate the last of the redundant memory accesses in my hottest code in a portable way, at a language/expression level.</div>
<div><br></div><div>Are you saying it's impossible, that you don't think it should be done, or it's already solved?</div><div>Is it that you don't see the value in it? Is that what I need to convince you of?</div>
<div>You haven't argued with any of the other points I raised, which leads me to suspect you either see my points, or you think the entire premise of my rant is wrong... if so, can you show how, and present a solution that's workable within existing constructs that meets my criteria without adding other implicit/logical baggage? Nobody has acknowledged or disputed the majority of my points :/</div>
<div><br></div><div>D is a native language, that's it's most attractive feature, and while I appreciate all the high-level correct-ness D offers, it still needs to get the low level right and ideally improve on existing offerings in meaningful ways to motivate new users to switch. This is a big un-checked checkbox for me and my colleagues, and I'd wager any low level realtime programmer out there who has had to struggle with the codegen in their inner loops.. doubly so if they ever work on non-x86 systems since the penalties are so much greater.</div>
</div>