Multiple return values...

Timon Gehr timon.gehr at gmx.ch
Sun Mar 11 12:32:32 PDT 2012


On 03/11/2012 07:57 PM, Andrei Alexandrescu wrote:
> 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.

static assert(is(TypeTuple!(int, double))); // it is a valid type.
static assert(is(typeof(TypeTuple!(int, double).init)));// there are 
values of that type.


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

He and others are concerned with both. =)

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

The suggestion was for language tuples.
static assert(TypeTuple!(int,int).stringof="(int, int)"); // =o!

There is nothing extremely bad about having to use "Tuple!", even if it 
is not that beautiful. The more annoying bit is unpacking them. More 
flexible type inference is desirable. Adding magic to the library tuple 
obviously is not. Therefore I was aiming at making the built-in tuples 
more powerful.

I currently see the issue this way:

- There is a pull for tuple unpacking syntax sugar.
- This is not merged because it is possibly not general enough.
- A more general solution will probably not be added to the language.


> [snip.]

Good points. However, adding multiple return values after the 
implementation is fleshed out still seems like a good idea.


More information about the Digitalmars-d mailing list