On Monday, 27 May 2013 at 02:31:50 UTC, Jonathan M Davis wrote:
On Monday, May 27, 2013 04:24:51 Diggory wrote:
It also shouldn't break any code since the only addition to
TypeTuple is a check to make sure that the undocumented
behaviour
of using it with non-types is disallowed, and in the case that
this undocumented feature is used the code can simply switch to
StaticTuple and be done.
Well, changing TypeTuple to only accept types _will_ break
code. It gets used
quite heavily with foreach to get a static foreach, and that
can involve using
expressions instead of types. Anyone using TypeTuple heavily
knows what it can
do and will probably have used it for expressions at some
point. It wouldn't
surprise me in the least if it's already done in Phobos, and
there's no way to
know how much it is or isn't done elsewhere.
Because you're generally in control of the TypeTuples that
you're using (you
aren't usually getting the from APIs and the like), I really
don' think that
the fact that it can hold both types and expressions is a big
deal. I expect
that it pretty much never causes problems in actual code. It
just makes it so
that the name sucks. I don't think that we'd gain much (if
anything) by
separating out TypeTuple into three different types. Renaming
it would be nice,
but given the current push to stop making breaking changes like
that, I would
expect that at best, we'd get an alias with a better name.
- Jonathan M Davis
Hmm, given that the fix can be entirely automated incredibly
simply with find and replace it doesn't seem that bad, especially
as the broken behaviour is undocumented. Given that the
documentation specifically disambiguates between TypeTuples and
ExpressionTuples I think at least emitting a warning when
non-types are used to a TypeTuple is reasonable.
