Multiple return values...

[Timon Gehr]

On 03/10/2012 05:16 AM, Andrei Alexandrescu wrote:
> On 3/9/12 3:59 PM, Timon Gehr wrote:
>> Yes, but we wouldn't have needed it if the built-in one would have been
>> considered sufficient.
>
> The goal is considering the language sufficient for implementing a
> useful structure such as Tuple in a library.

I am not saying it is not awesome that the language is powerful enough 
to implement a thing like std.typecons.Tuple, but Tuple is too basic to 
be implemented meaningfully in a library. That is why 
std.typecons.Tuple's implementation depends on built-in _tuples_.

Furthermore, it shows that there is a minor language insufficiency: It 
is impossible to overload the static index or slice operators.


> Same goes about associative arrays.
>

Associative arrays are proper built-in types. The rest is an 
implementation detail.

>> - Returning it from a function is not efficient.
>
> Implementation issue, if at all.

The ABI is part of the design, even if open-ended.

> Solving that will optimize the return
> of any structure in any D code.
>

That would presumably reduce the efficiency of built-in structs in some 
other cases.

>> - It does not play very nicely with type deduction.
>
> It plays by the rules enacted by the D programming language. If those
> aren't nice, there's a problem with them rules. If you like them rules
> but want "special" rules for templates, you're asking for magic. Magic
> smells.
>

immutable int* p;
(auto x, const(int)* y) = (p, p);

I'm not spotting any templates.

>> - It has clumsy syntax and is therefore rarely used.
>
> Then templates have clumsy syntax and therefore are rarely used.
>

... for implementing basic language constructs.

>> 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.
>
> This is because we need to think about that stuff to maximize its
> generality.
>

... without screwing with existing syntax. That is the only thing that 
makes it hard. Making built-in tuples more powerful and accessible 
across the board would be a reasonably general solution.

>> - It is a trivial wrapper for an underpowered built-in type. This causes
>> confusion.
>
> It's not quite trivial.
>

What is non-trivial about it?
I know that making implementation of trivial things mind-bending is 
appreciated in the C++ community, but in D it often really *is* trivial.