Thu, 07 Oct 2010 13:45:16 -0400, Michel Fortin wrote: > On 2010-10-07 12:34:33 -0400, Andrei Alexandrescu > <seewebsiteforem...@erdani.org> said: > >> My suggestion is that we deprecate TypeTuple and we call it AliasTuple >> because that's really what it is - it's a tuple of stuff that can be >> passed in as an alias parameter. > > Personally, I like D built-in tuples; they're so simple. At the core > they're just a group of "things". If you put only types in the tuple > then it becomes usable as a type, and if you put only values in the > tuple then it becomes usable as a value, and if I put variable > declarations in the tuple then it becomes usable as a single variable > aliased to all those variables, and if I mix all kind of things then > it's just a heterogenous tuple that's probably only suitable as a > template parameter. > > Why should I know beforehand if I'm defining an alias tuple, a type > tuple, a value tuple, or a whatever tuple? Seriously, the tuple is just > a group of those "things" I put in it, and the compiler will tell me > whenever I try to put that tuple where it doesn't belong. > > Now, it sure would make sense to have a way to enforce whether a tuple > is valid as a type or a valid as a value. But for many uses it isn't > necessary, and it does simplify things to not have to care about it.
We were discussing the semantics of the language. You can't design languages & compilers by just saying "do it the simple way, it should just work". The tuples & proposals are already combining several different features: tuples, records, arrays (slices & indexing), varargs, type definitions (type tuples), dependent types, pattern matching, nominative & structural typing, and ad-hoc features (.tupleof which.. in fact isn't any of the three listed tuples). On top of that there are syntactical conflicts. How is that in any possible way simple?