On Mon, 24 Sep 2012 01:01:29 -0400, Nick Sabalausky
<seewebsitetocontac...@semitwist.com> 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?
(int[]) x;
int a = x.length;
is a == 0 or 1?
I agree with Andrei, we need something different.
I don't profess to be even close to an expert on tuples, but I feel they
should be built-in to the language, since they are actually language
constructs that we are declaring types for.
Without any research or investigation, what about using a different set of
delimiters for tuples? Like {1,2,3}
Right now, I think that is reserved for static struct initializers. But
can't those be considered a tuple also? Someone will probably destroy
this 10 milliseconds after I send it :)
-Steve
