Multiple return values...

[Manu]

On 11 March 2012 05:04, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> On 3/10/12 4:37 AM, Manu wrote:
>
>> I still fundamentally see a clear divide between a Tuple, which is a
>> deliberately structured association of multiple values, and 'multiple
>> return values' which is an explicit non-association of multiple returned
>> things.
>>
>
> There is no difference. A Tuple is a product type, exactly like
> superposing arbitrary values together.


So you're saying that whatever I think about the implementation of Tuple is
wrong? It is not actually a structured type?


> You need to address that principle before I can begin to accept the idea
>> of abusing a structured tuple as a substitute for this important
>> language feature.
>>
>> My analogy is the function argument list. You don't think of the
>> arguments you pass to a function as a Tuple (is it implemented
>> internally in this way? if so, it is well hidden, and perhaps similar
>> magic can be done...)
>> You pass, TO a function, multiple un-associated values.
>>
>
> 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.


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

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.

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.

Are you saying it's impossible, that you don't think it should be done, or
it's already solved?
Is it that you don't see the value in it? Is that what I need to convince
you of?
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 :/

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120311/66aedcf1/attachment-0001.html>