Le 24/09/2012 03:14, Andrei Alexandrescu a écrit :
On 9/23/12 7:08 PM, deadalnix wrote:
Le 24/09/2012 00:48, Andrei Alexandrescu a écrit :
This notion a lot of trouble with it; I think it's safe to abandon it
entirely.
Once a one-element tuple becomes equivalent to the actual item, there's
an explosion of trouble and special cases in the language and in code
that uses it. For example, divide and conquer code that manipulates
tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to
cases in which the slices are no longer tuples, and so on. And that's
only the beginning.
This is a very weak point. In most cases, divide an conquer with tuple
don't even make sense.
The example came from min() applied to built-in "T..." tuples. I've
implemented it a few times, and I recall at some point there was a
compiler bug related to zero-length tuples. It was rather awkward to
address. But there are many other cases. In my opinion, introducing a
change of phase at length=1 is just causing trouble.
Andrei
I understand the trouble here. But why divide and conquer is preferable
here over a static foreach over the tuple ?
Additionally, what lead me to think the idea is good is how tuple can be
used to call function, or to extend the opDispatch feature to templated
calls.
I didn't wanted to go into such details, because I wanted to test
several idea before doing a proposal. A lot of options are possible
here, and interaction with other part of the language are everywhere.
