Multiple return values...

[Timon Gehr]

On 03/10/2012 12:27 AM, Andrei Alexandrescu wrote:
> On 3/9/12 10:16 AM, Timon Gehr wrote:
>> There are two parts, syntax and semantics.
>>
>> Semantics:
>> D is already able to express those:
>>
>> template Tuple(T...){alias T Tuple;} // not the same as
>> std.typecons.Tuple!
>>
>> // function with multiple return values:
>> Tuple!(int,double) foo(int a, double b){
>> Tuple!(int, double) result; // ok, _no imposed memory layout_
>> result[0] = a; // ok
>> result[1] = a+b; // ok
>> return result;
>> }
>>
>> Multiple return values are currently *disallowed explicitly*:
>> DMD sez: "Error: functions cannot return a tuple"
>>
>> Just specify the ABI, implement the code gen, and we're done.
>>
>> Moot point: built-in tuples auto-flatten inside comma-separated lists.
>>
>> std.typecons.Tuple is a hack to circumvent the arbitrary "cannot return
>> tuple from function" restriction as well as the auto-flattening.
>
> No, it was more like an implementation of a generic tuple.
>

Yes, but we wouldn't have needed it if the built-in one would have been 
considered sufficient. It is akin to implementing an 'Int' struct in the 
standard library that wraps a built-in 'int' but does not implicitly 
convert to unsigned.

>> The
>> problem is that it is implemented as a struct with a built-in tuple
>> member. The fact that it is a struct imposes a memory layout. This is
>> just a side-effect of attempting to address the other two issues. It is
>> not something that is desirable.
>
> Why?
>
> I don't understand what you're trying to solve, that Tuple is not good at.
>
>
> Andrei

Off the top of my head:

- Returning it from a function is not efficient.

- It does not play very nicely with type deduction.

- It has clumsy syntax and is therefore rarely used.

Notably, there is no convenient unpacking syntax. Walter does not merge 
the patches of Kenji Hara that would fix this because presumably he 
fears it could get in the way of a more general solution.

- It is a trivial wrapper for an underpowered built-in type. This causes 
confusion.


This situation is neither particularly pragmatic nor pure enough. I'd 
call it a wart.