Tue, 17 Nov 2009 14:38:57 -0800, Bill Baxter wrote: >> I agree, a tuple of one element (doesn't matter what type, array in >> this case) should be semantically identical to that single element. >> >> proper semantics for language supported tuples should IMO include: 1) >> syntax to explicitly [de]construct tuples and no auto-flattening 2) a >> tuple of one element is identical to a scalar: >> int a = 5; // scalar integer >> auto b = (5); // tuple of one integer a == b // is true > > Interesting. It does kinda make sense. So should indexing work too? > And properties? 5[0] == 5? 5.length == 1? If not that could be painful > for functions that process generic N-tuples. If so then what does that > do if the "scalar" type happens to be float*?
In some languages () is a distinct Unit type. Tuples are defined recursively from the Pair type, e.g. Pair[int,int], Pair[int, Pair [int,int]] === (int,int,int). And have a special indexing syntax with 1- based indexing. > >> 3) function's argument list is a tuple like in ML: >> void foo(int a, char b); >> int a = 5; char b ='a'; >> auto tup = (5, 'a'); >> foo(a, b) is identical to foo(t); Tuples can't encode things like by-ref, by-val, lazy etc. > That seems like a kind of auto-flattening. Shouldn't (t) be a tuple of > a tuple? > What if you have an actual tuple in the signature, like void foo((int > a,char b))? > Or you have both overloads -- foo(int,char) and foo((int,char)) I think > I like Python's explicit "explode tuple" syntax better. > foo(*t) > Probably that syntax won't work for D, but I'd prefer explicit > flattening over implicit. Good boy. > >> 4) unit type defined by the empty tuple instead of c-like void > > This is kind of neat, but does it actually change anything? Or just > give an aesthetically pleasing meaning to void/unit? The empty tuple can be considered to be the unit type.
