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.
