Discussion of TypeTuple naming

[Diggory]

On Monday, 27 May 2013 at 13:42:51 UTC, Timon Gehr wrote:

> It is not that similar, as it automatically expands into any 
> context and hence does not allow a nested structure.

The point being? It's true that there is some special behaviour, 
but that's the same regardless of whether it's called StaticTuple 
or TypeTuple.

> I don't think that having a construct that is restricted to 
> just types makes a lot of sense.

In a language which is most emphatically statically typed with 
built in support for class invariants and in/out contracts you 
can't see the purpose of a TypeTuple?

> TypeTuple does not implement any functionality. It is an 
> 'identity function'.

And yet the documentation:

http://dlang.org/tuple.html (see Type Tuples)

And the name clearly suggest that it DOES implement functionality 
- that of checking that the arguments are all types.



On Monday, 27 May 2013 at 19:13:24 UTC, Andrej Mitrovic wrote:

> You are forgetting about performance. TypeTuple can be used *a 
> lot* in
> generic code. If you add static checking for each tuple element 
> you're
> going to slow down the compiler quite a bit. And you won't know 
> this
> if you only sporadically use TypeTuple.

Actually, given that all the template parameters are likely 
already being used (otherwise why have that parameter) the 
checking must already occur simply further down the line.

In addition, I've run some tests using thousands of huge 
recursively defined tuples and I haven't been able to get any 
detectable different between using TypeTuple and StaticTuple. 
Unless someone can demonstrate some code which has a measurable 
difference in compilation time I think performance is not an 
argument.

> It's not undocumented behavior, it's documented, e.g. The D 
> Templates Book.

Fine, not documented on the official dlang site, or rather it's 
specifically documented that TypeTuples are only for storing 
types.

> Where do you get this clarity that it's only used for types? 
> Have you
> inspected all D libraries out there?

Of course not, my "clarity" comes from having gone through phobos 
and identifying which uses of TypeTuple would have to be changed 
to using StaticTuple.

The only significant cases of it being used with non-types 
outside std.typetuple itself were in std.traits, which is hardly 
typical D code and is one file in a large library anyway.

Hence my statement that most uses of TypeTuple were with types 
was based on the fact that it's true in phobos and therefore 
likely true in any sufficiently large code-base. Especially 
considering that significant contributers to phobos are more 
likely to know that using TypeTuple with non-types is allowed 
than the average user of D.

> It's not, because now you're forced to always compile with the
> deprecation switch.

As Jonathan said that's not true anymore.




On Monday, 27 May 2013 at 19:30:18 UTC, Jonathan M Davis wrote:

> That being said, I don't really like the idea of deprecating 
> something with the intention that it stick around forever. It 
> just provides a smoother transition.

OK, let me amend my statement to "the transition can be as smooth 
as it needs to be".

> Yeah. The only problem I see is the name. I don't see any real 
> benefit in making it so that we have _three_ different types of 
> compile time tuples, particularly when their uses tend to be 
> fairly localized rather than being passed around through APIs 
> and the like (if they get passed through APIs, they'd just be 
> template or function argument lists), and any mismatch of types 
> and expressions will result in an error pretty much instantly.

Three? I am suggesting TWO, "StaticTuple" and "TypeTuple" with 
further additions for a future discussion.

It gives good names to concepts we already have but have no way 
to refer to consistently. The term "TypeTuple" as used to mean a 
compile time tuple which contains types has a whole section in 
the documentation.

Currently we don't have any way to talk about StaticTuples 
without being ambiguous and confusing. We can't use the term 
"TypeTuple" because that is already used as I've just described, 
and we can't use the term "Tuple" even though that is what's 
currently used in most places because a "Tuple" is something 
completely different in phobos!

Using StaticTuple clearly and unambiguously refers to the alias 
to a "..." template argument.

If a function's documentation says it accepts any StaticTuple 
then it's clear what that function expects. Likewise for 
TypeTuple. At the moment there's no way to determine whether a 
function can accept non-types without going through the phobos 
source code.

> So, holding both expressions and types isn't really a problem 
> IMHO - particularly since that's what the built-in tuples do, 
> and all TypeTuple really is is a template to let you create and 
> manipulate the built-in tuples.

I assume you are refering to what I am calling a StaticTuple 
rather than a Tuple in this case, because not so long ago I would 
have assumed that when you said "built-in tuple" you meant 
std.tuple.Tuple.

> So, if we change anything, we change the name via an alias and 
> leave all of the semantics alone. But given how much TypeTuple 
> is used and that the module is named std.typetuple, it would 
> likely have to be a permanent alias, in which case you _still_ 
> have to explain what TypeTuple is, and the gain of renaming it 
> is minimal IMHO (it could even make things _worse_ by 
> increasing the confusion by having multiple names).

TypeTuple is currently described in the documentation as a 
compile time tuple which contains types. This is still the case 
after introducing StaticTuple...

The only difference is that now the description is actually 
correct.

> The name sucks, but I think that we're stuck with it at this 
> point. For it to be worth it, we'd have to be willing to force 
> everyone to change their code to use the new name, and for the 
> most part, we're just not doing that sort of thing anymore.

This makes no sense. All of the benefits of StaticTuple come 
without changing any existing code except for in phobos itself, 
in particular a logical naming system which actually matches the 
existing documentation.