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