On Monday, 27 May 2013 at 13:42:51 UTC, Timon Gehr wrote:
It is not that similar, as it automatically expands into any
context and hence does not allow a nested structure.
The point being? It's true that there is some special behaviour,
but that's the same regardless of whether it's called StaticTuple
or TypeTuple.
I don't think that having a construct that is restricted to
just types makes a lot of sense.
In a language which is most emphatically statically typed with
built in support for class invariants and in/out contracts you
can't see the purpose of a TypeTuple?
TypeTuple does not implement any functionality. It is an
'identity function'.
And yet the documentation:
http://dlang.org/tuple.html (see Type Tuples)
And the name clearly suggest that it DOES implement functionality
- that of checking that the arguments are all types.
On Monday, 27 May 2013 at 19:13:24 UTC, Andrej Mitrovic wrote:
You are forgetting about performance. TypeTuple can be used *a
lot* in
generic code. If you add static checking for each tuple element
you're
going to slow down the compiler quite a bit. And you won't know
this
if you only sporadically use TypeTuple.
Actually, given that all the template parameters are likely
already being used (otherwise why have that parameter) the
checking must already occur simply further down the line.
In addition, I've run some tests using thousands of huge
recursively defined tuples and I haven't been able to get any
detectable different between using TypeTuple and StaticTuple.
Unless someone can demonstrate some code which has a measurable
difference in compilation time I think performance is not an
argument.
It's not undocumented behavior, it's documented, e.g. The D
Templates Book.
Fine, not documented on the official dlang site, or rather it's
specifically documented that TypeTuples are only for storing
types.
Where do you get this clarity that it's only used for types?
Have you
inspected all D libraries out there?
Of course not, my "clarity" comes from having gone through phobos
and identifying which uses of TypeTuple would have to be changed
to using StaticTuple.
The only significant cases of it being used with non-types
outside std.typetuple itself were in std.traits, which is hardly
typical D code and is one file in a large library anyway.
Hence my statement that most uses of TypeTuple were with types
was based on the fact that it's true in phobos and therefore
likely true in any sufficiently large code-base. Especially
considering that significant contributers to phobos are more
likely to know that using TypeTuple with non-types is allowed
than the average user of D.
It's not, because now you're forced to always compile with the
deprecation switch.
As Jonathan said that's not true anymore.
On Monday, 27 May 2013 at 19:30:18 UTC, Jonathan M Davis wrote:
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.
OK, let me amend my statement to "the transition can be as smooth
as it needs to be".
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.
It gives good names to concepts we already have but have no way
to refer to consistently. The term "TypeTuple" as used to mean a
compile time tuple which contains types has a whole section in
the documentation.
Currently we don't have any way to talk about StaticTuples
without being ambiguous and confusing. We can't use the term
"TypeTuple" because that is already used as I've just described,
and we can't use the term "Tuple" even though that is what's
currently used in most places because a "Tuple" is something
completely different in phobos!
Using StaticTuple clearly and unambiguously refers to the alias
to a "..." template argument.
If a function's documentation says it accepts any StaticTuple
then it's clear what that function expects. Likewise for
TypeTuple. At the moment there's no way to determine whether a
function can accept non-types without going through the phobos
source code.
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.
I assume you are refering to what I am calling a StaticTuple
rather than a Tuple in this case, because not so long ago I would
have assumed that when you said "built-in tuple" you meant
std.tuple.Tuple.
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).
TypeTuple is currently described in the documentation as a
compile time tuple which contains types. This is still the case
after introducing StaticTuple...
The only difference is that now the description is actually
correct.
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.
