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.
