On 9/24/12 1:01 AM, Nick Sabalausky wrote:
On Sun, 23 Sep 2012 18:48:22 -0400
Andrei Alexandrescu<seewebsiteforem...@erdani.org> wrote:
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.
I think one of us is missing something, and I'm not entirely sure
who.
As I explained (perhaps poorly), the zero- and one-element tuples *would
still be* tuples. They would just be implicitly convertible to
non-tuple form *if* needed, and vice versa. Do you see a reason why
that would *necessarily* not be the case?
It just creates endless little problems and confusion coming outta the
woodwork, as others have pointed out in response to this. There are
languages that have also explored a similar approach - a value can be
automatically converted to a one-element array and vice versa. It's
problematic, especially in a language with generics and function
overloading.
I think it's safe to just not even discuss it.
A nice way to put it :/ Part politician perhaps? ;)
I meant it in a simple and forward way - all I want is to save time and
trouble in exploring a no-win design. From sheer experience gathered
from years at hacking at this stuff I know this can be done but is not
worth the trouble. Since it can be done, there's no argument that would
definitively close the discussion, and that demotivates me from coming
up with explanations.
Andrei
