Tuple/TypeTuple etc.

Denis has been complaining about this for ages and I think it's worth doing something about.

Definitions:

std.typecons.Tuple
A bit like python's tuples. It's a heterogeneous collection of runtime values with compile-time determined types.

std.typetuple.TypeTuple
A heterogeneous *compile-time* collection of types, expressions and aliases.


Problems:

TypeTuple isn't just a typetuple, it's an everythingtuple. It's a terrible name that is confusing to newcomers (and even to people who've used D a lot but not delved in to the CT capabilities so much).

TypeTuple looks too much like Tuple. It's a totally different concept but the names are too similar.


Possible solutions:

1) rename TypeTuple in-place to something better. This is not a real option as it would break far too much code.

2) Introduce a new tuple constructor with a new name, and deprecate TypeTuple

2a) A whole new module, leaving std.typetuple as effectively an alias to the new module. Denis has a pull for this[1], which also adds new tuple constructors specialised for expressions.


I like Denis' pull request. It fixes the problem in a backwards compatible manner. However - as Jonathan points out in the comments - the naming is still a problem. GenericTuple, ExpressionTuple etc. all sound like they could be related to std.typecons.Tuple

So, we need a new name:
Sequence, ArgList or ParamList are possible suggestions.


A possible complete path to getting this sorted, using Sequence as an example:

1) Create a new module like in Denis' PR, called std.sequence and containing the template Sequence, equivalent to current std.typetuple.TypeTuple

1a) optional: include specific templates like TypeSequence and ExpressionSequence.

2) Leave std.typetuple as an alias to the new module, including alias TypeTuple = Sequence; Deprecate it.

3) std.traits.isTypeTuple becomes isTypeSequence and isExpressionTuple becomes isExpressionSequence.   Deprecated aliases from the old names are left for compatibility.

4) Change phobos over to using std.sequence (note that this is not required immediately, as there is 100% backwards compatibility).

The only remaining headache would be people getting confused by dmd spewing out complaints about tuple(blah, blah, blah), but that's a relatively minor concern.


P.S. please note that deprecating is not breaking, per se. Deprecations are just warnings by default. Also, although having compatibility aliases floating around is annoying, it's an unfortunate necessity if one wants to change things while not breaking everyone's code. I think it's a model we're going to have to get used to in order to be both flexible and reliable.

[1] https://github.com/D-Programming-Language/phobos/pull/780

On Friday, 16 August 2013 at 16:08:42 UTC, bearophile wrote: > John Colvin: > >> Possible solutions: > > My vote is for solution n.5: > > Add the built-in t{} syntax to denote all kind of tuples. This. With an exception of "I don't care what syntax is". There has been a thread in D.learn by Ali recently http://forum.dlang.org/post/kuk8uc$30th$1@digitalmars.com - it pretty much highlights there we have plenty issues with the very behavior of TypeTuple, not only naming. I know we are very reluctant to do language changes but this continues to do more and more damage to the language - it requires extra costs to maintain Phobos properly, confuses newcomers and complicates language specification itself as new corner cases get attention. What was the general attitude to http://wiki.dlang.org/DIP32 ?

On Fri, Aug 16, 2013 at 06:08:36PM +0200, bearophile wrote: > John Colvin: > > >Possible solutions: > > My vote is for solution n.5: > > Add the built-in t{} syntax to denote all kind of tuples. [...] This can be part of the solution, but by itself is not good enough, because the so-called "typetuple" and std.typecons.Tuple are NOT the same thing. They are completely unrelated types, in fact incompatible concepts, and we need some way to indicate that they aren't the same thing. Otherwise they will continue to cause confusion. The so-called "typetuple" (what dmd calls a "tuple") is a compile-time construct that can contain types, aliases, compile-time values, etc., that only exist at compile-time. On the contrary, std.typecons.Tuple is a runtime object that contains a sequence of values stored in memory (it has nothing to do with what dmd calls a "tuple"). The two are NOT the same thing. I think a good start is to call them by different names. The word "tuple" is just too overloaded right now, and using the same term to refer to two incompatible things is just formula for endless confusion. "Sequence" is OK, but risks confusion with std.range.sequence. Is there a better word for it? Maybe an acronym -- CTS (compile-time sequence)? T -- Guns don't kill people. Bullets do.

On Friday, 16 August 2013 at 16:28:29 UTC, H. S. Teoh wrote: > I think a good start is to call them by different names. The word > "tuple" is just too overloaded right now, and using the same term to > refer to two incompatible things is just formula for endless confusion. > "Sequence" is OK, but risks confusion with std.range.sequence. Is there > a better word for it? Maybe an acronym -- CTS (compile-time sequence)? > > > T Typetuple allows random access to elements, so maybe array is better than sequence. Compile-Time annotation is very nice as it explicitly states the usage and capabilities of the construct. Also - the acronym is already known thanks to CT-FE.

On 08/16/2013 09:27 AM, H. S. Teoh wrote: > The so-called "typetuple" (what dmd calls a "tuple") is a compile-time > construct that can contain types, aliases, compile-time values, etc., > that only exist at compile-time. They are all symbols, right? And symbols live only at compile time. ... > "Sequence" is OK, but risks confusion with std.range.sequence. Is there > a better word for it? Maybe an acronym -- CTS (compile-time sequence)? SymbolTuple it is! :) Ali

On Fri, Aug 16, 2013 at 11:10:28AM -0700, Ali Çehreli wrote: > On 08/16/2013 09:27 AM, H. S. Teoh wrote: > > > The so-called "typetuple" (what dmd calls a "tuple") is a compile-time construct that can contain types, aliases, compile-time values, etc., that only exist at compile-time. > > They are all symbols, right? And symbols live only at compile time. > > ... > > > "Sequence" is OK, but risks confusion with std.range.sequence. Is there a better word for it? Maybe an acronym -- CTS (compile-time sequence)? > > SymbolTuple it is! :) [...] +1, I like this! I still don't like the use of "tuple", but I think "symbol" makes it abundantly clear what these things are. I vote for SymbolTuple. T -- Живёшь только однажды.

On Friday, 16 August 2013 at 18:10:29 UTC, Ali Çehreli wrote: > On 08/16/2013 09:27 AM, H. S. Teoh wrote: > > > The so-called "typetuple" (what dmd calls a "tuple") is a > compile-time > > construct that can contain types, aliases, compile-time > values, etc., > > that only exist at compile-time. > > They are all symbols, right? And symbols live only at compile time. Not really. At least as far as my understanding goes, for example, integer literals are not symbols. Symbols usually uniquely identify something (and are possibly emitted to object files) and this is not the case for compile-time tuple elements. Symbols are most closely related to `alias` parameters (it does have inconsistencies of its own though).

On 08/16/2013 11:21 AM, H. S. Teoh wrote: > On Fri, Aug 16, 2013 at 11:10:28AM -0700, Ali Çehreli wrote: >> On 08/16/2013 09:27 AM, H. S. Teoh wrote: >> >>> The so-called "typetuple" (what dmd calls a "tuple") is a >>> compile-time construct that can contain types, aliases, compile-time >>> values, etc., that only exist at compile-time. >> >> They are all symbols, right? And symbols live only at compile time. >> >> ... >> >>> "Sequence" is OK, but risks confusion with std.range.sequence. Is >>> there a better word for it? Maybe an acronym -- CTS (compile-time >>> sequence)? >> >> SymbolTuple it is! :) > [...] > > +1, I like this! I still don't like the use of "tuple", Same here: tuple is confusing. :/ I also thought about SymbolList but then it doesn't go well with random accessing its elements. > but I think > "symbol" makes it abundantly clear what these things are. > > I vote for SymbolTuple. Me too! :p Ali

Forums