Multiple return values...

[Andrei Alexandrescu]

On 3/11/12 6:50 AM, Manu wrote:
> On 11 March 2012 05:04, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>>
>     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?

I don't know what you mean by "structured type". What I mean by "product 
type" is this: http://en.wikipedia.org/wiki/Product_type

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

I am convinced you are underestimating. The notion that a function 
returns one typed value is strongly embedded in the language and the 
standard library.

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

I think you and others are concerned with different aspects 
(incrementally pleasant syntax vs. efficiency).

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

D can return multiple values from a function by putting them in a tuple. 
This approach has many advantages, mostly related to avoiding awkward 
ambiguities (e.g. forwarding the result of a multi-return to a variadic 
or overloaded function). Regarding syntax, I am not convinced by 
arguments predicated on removing "Tuple!" from "Tuple!(int, int)". It's 
not progress, and pouring more magic in tuples that is not available 
anywhere else does not strike me as a good path to go.

Regarding low-level efficiency, the main issue is that structs and 
function argument lists have distinct layouts. Consider:

import std.stdio, std.typecons;
int a(int b, int c) {
     return b + c;
}
auto foo() {
     return tuple(1, 1);
}
void main() {
     writeln(a(foo().expand));
}

An adjustment may be needed from the output of a() to the arguments of 
foo(). (Probably not in this case.) I understand that someone very 
concerned with low-level performance would scrutinize such code 
carefully. But I also believe that the same person is willing to forgo a 
whole category of language and library features that don't fulfill a 
demanding performance profile.

> 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?

I understand your pledge, and all I'm saying is that it is very 
difficult to implement (Walter and I discussed the matter many times 
over the years) and the feature will benefit only very, very few.

> 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 :/

Your points are understood, but please also understand what exceptional 
circumstances you are invoking. You mention how transferring function 
results costs extra operations. If that cost is significant, that means 
the cost of the function proper is extremely low. So you want to call 
extremely small functions in extremely core loops. The first advice 
would be "avoid calling extremely small functions in extremely core loops"!

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

Are function returning tuples the first thing on your low-level 
efficiency list?


Andrei