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.
