On Tue, Nov 17, 2009 at 3:57 PM, retard <[email protected]> wrote: > 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.
That wasn't really the question. It was what should 5[0] do in D, if scalars are considered to be 1-tuples? I think that's a killer for 1-tuple / scalar equivalence in D. Neither behavior is acceptable in my opinion. So it seems you can't have 1-tuple/scalar equivalence unless you have a distinct tuple-indexing syntax. Right now std.typecons.tuple uses x.at!(0) because you can't have a x[i] return different types, but the built-in "A..." template tuples do it. So that's something that needs to be fixed anyway, because "good for me but not for thee" is lame. (Took that phrase from a review of Go...) I think probably D should allow a templated opIndex!(int) so that user types can implement tuple-like indexing where each index could be a different type. Or we should try to come up with another syntax for indexing tuples. >>> 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 does seem to kill that idea. >> 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. Yes, Yigal said basically that. The question I have is what practical difference does that make to the language? Seems no different from defining the empty tuple to be void, then renaming void to unit. --bb
