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. Same goes about associative arrays.
- Returning it from a function is not efficient.
Implementation issue, if at all. Solving that will optimize the return of any structure in any D code.
- 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.
- It has clumsy syntax and is therefore rarely used.
Then templates have clumsy syntax and therefore are 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.
This is because we need to think about that stuff to maximize its generality.
- It is a trivial wrapper for an underpowered built-in type. This causes confusion.
It's not quite trivial.
This situation is neither particularly pragmatic nor pure enough. I'd call it a wart.
I'd call it a great artifact. Love the Tuple (and the Drake). Andrei
