Discussion of TypeTuple naming

Jonathan M Davis jmdavisProg at gmx.com
Mon May 27 17:45:23 PDT 2013


On Tuesday, May 28, 2013 00:23:08 Diggory wrote:
> On Monday, 27 May 2013 at 19:30:18 UTC, Jonathan M Davis wrote:
> > 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.

I thought that you were suggesting ExpressionTuple on top of the other two. 
Regardless, I see no reason to add yet more tuple types. Two is plenty. It's 
just that the name for TypeTuple sucks, because it's used for more than just 
types and arguably isn't a tuple to begin with (since it doesn't have 
nesting).

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

Right now, that's TypeTuple. The fact that Type is in the name means nothing 
other than the fact that it was poorly named. I'm quite certain that a number 
of the template-heavy projects out there use TypeTuple for expressions as well 
as types. I know that I have. You pretty much have to if you want to use 
expressions with static foreach.

> because not so long ago I would
> have assumed that when you said "built-in tuple" you meant
> std.tuple.Tuple.

std.typecons.Tuple isn't built-in. It's in the standard library. When I say 
built-in, I meant built into the language.

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

If you introduce StaticTuple on top of TypeTuple, even without 
ExpressionTuple, you now have three different tuple types to explain, whereas 
now we only have two (which is already problematic enough). If you create an 
alias from TypeTuple to StaticTuple, then you only really have two tuple 
types, but you still have three of them in code, so you stil have to explain 
three of them.

The documentation on TypeTuple is just plain wrong, and anyone who uses it 
much knows fulwell that it's wrong, so I consider it to be pretty much 
irrelevant. I think that the design of TypeTuple is perfectly sound - it's 
merely a way to create the tuples which are built into the language. It's just 
that a bad name was chosen. If we were willing to break code for name changes, 
I'd argue for changing it to something like StaticTuple, but Walter and Andrei 
are flat-out against that at this point. The ROI is too low for the amount of 
breakage that it causes - especially with something as heavily used as 
TypeTuple. If we were going to change the name, we should have changed it ages 
ago. I don't think that it's going to be acceptable to do so now, and I don't 
think that the confusion caused by adding an alias to it is an improvement. 
And I definitely don't think that trying to split out TypeTuple into a tuple 
that actually is a way to use the built-in tuple (like it is now) and one that 
only takes types is an improvement.

So, I agree that the name sucks, and it would be great if we could change it, 
but at this point, I think that we're stuck, and we obviously need to fix the 
documentation to clarify it.

- Jonathan M Davis


More information about the Digitalmars-d mailing list