Discussion of TypeTuple naming

Jonathan M Davis jmdavisProg at gmx.com
Mon May 27 12:30:04 PDT 2013


On Monday, May 27, 2013 21:13:10 Andrej Mitrovic wrote:
> On 5/27/13, Diggory <diggsey at googlemail.com> wrote:
> > - There's no necessity to ever actually completely remove the
> > deprecated behaviour, the deprecation warning is enough.
> 
> It's not, because now you're forced to always compile with the
> deprecation switch.

That's not true anymore. Deprecations only print out warning messages by 
default, precisely so that we can deprecate things without breaking everyone's 
code. -d makes the compile shut up, but it is no longer required to get your 
code to compile. 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.

> All I see here is the problem with the actual *name* of the template.
> If it's so horrible to use this name, the simplest thing we can do is
> introduce an alias to TypeTuple, ala "Seq" or "ExpressionTuple", or
> something similar.
> 
> Of course "TypeTuple" is a misnomer, but it's way too late to change
> it now or even change its semantics. Even slowing it down by doing
> type-checking is a problem.

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. 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.

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).

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.

- Jonathan M Davis


More information about the Digitalmars-d mailing list