> 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*? > 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); 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. > 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? --bb
