Discussion of TypeTuple naming

[Diggory]

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

There's no point explaining it to me - I know what they are, and 
the only reason I know is because I've gone through and looked at 
the phobos code for both of them, something I shouldn't have to 
do.

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

Sometimes explaining more things is better than explaining fewer 
things. Having recently gone through the process of learning 
about D tuples I can safely say that if instead "StaticTuple", 
"TypeTuple" and "Tuple" were explained it would have been much 
easier to understand.

Are you really arguing that the existing system is easier to 
understand?

A simple note that TypeTuple may be used in existing code to 
store non-types but that this usage is deprecated is enough to 
explain the entire situation to anyone, and even this is not 
necessary to remember unless you are specifically editing code 
written before StaticTuple.

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

How on earth is anyone supposed to know this if the documentation 
is wrong without going through the code. IMO the reason D has had 
such limited uptake despite all of its positive features has 
nothing to do with being too unstable, it's because every 
possible barrier is put up against novice programmers getting 
started with the language. A language grows in popularity because 
new people start using it, not because company X decides it's now 
crossed some imaginary stability threshold.

There seems to be some illusion that being stable is about 
drawing a line and saying "from now on there will be no more code 
breakage". That's not being stable, that's not fixing problems 
with the language. A language is stable when sufficiently many of 
the problems that would require code changes have been fixed so 
that the remaining problems can be fixed without breaking code. 
The only possible outcome is either fixing the problems later 
which is worse because you break more code, or never being able 
to fix the problems satisfactorily (C++).

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

What is the worst possible scenario if this change was 
implemented? Answer: some projects generate deprecation warnings 
until somebody can be bothered to press ctrl+H or *insert 
shortcut of your choice for replace all*. It won't actually break 
any code, so it's not a case of breaking code for name changes.

The questions after the most recent dconf talk discussed an 
automatic conversion tool for upgrading code, and most of the 
people concerned with breaking changes were happy for those 
changes to occur if it was no effort for them to update the code. 
In this case I am not even suggesting breaking code, plus it's 
possible to upgrade the code using an automated tool that 
everyone already has.

The benefits are significant. Maybe to someone who knows D inside 
out it doesn't matter but you have to cater to newcomers both now 
and in the future, not just existing users. If not, D will 
stagnate.

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

IMO, StaticTuple + TypeTuple + Good documentation is less 
confusing than TypeTuple + Good documentation. Plus the former 
reflects better on the language. Seeing the former and reading 
about TypeTuple I would think D is a language where the problems 
have been fixed (without code breakage). Seeing the latter I 
would think D is a language where things that are broken will 
never be fixed.

In the former the bit that needs some more explanation is the 
exception to the rule (TypeTuple with non-types). In the latter 
the bit that needs some more explanation is the rule itself 
(TypeTuple is not actually a TypeTuple).

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

Given that there is special treatment in the compiler for when 
all the parameters are types it seems absurd not to have a name 
for tuples which meet the criteria.