On Tuesday, 20 August 2013 at 13:57:49 UTC, Dicebot wrote:
Syntax sugar will only hide and eventually increase confusion,
it won't solve the semantical issue. This is why we are having
this topic IMHO, bunch of quite experienced D developers can't
even agree on how existing feature behaves :) Including those
who is it all the time! It is clear indicator that syntax is
not the one to blame.
My suggestions are predicated on the fact that I think tuples are
more or less fine as-is. They just need some syntactic sugar for
literals and destructuring/pattern matching to make them more
usable. Built-in tuples are confusing, I think, because they're
named TypeTuple, which makes people conflate them with
std.typecons.Tuple.
Another reason is that TypeTuple can contain both values and
types at the same time, so it's confusing as to what you can do
with them.
"Why can you only assign a TypeTuple to a variable if it contains
values but not types? Why, then, can't you return TypeTuple!(1,
2.3) from a function? Is it not really a variable? Why does
`alias t = TypeTuple!(1, 2.3)` work, but `alias n = 3` not work?
Is this f*$#ing thing a value or a type?" - D Newbie
Everything else aside, I think the best possible change that
would make the whole tuple situation better is to limit or
outright ban the mixing of values and types within TypeTuple.
Even better is to always treat TypeTuple as a type, and not a
value. That ship has already sailed, but we can at least try to
enforce it through convention.
I am proposing something more radical. Deprecate _both_
TypeTuple and Tuple. Clearly define the difference between
built-in type tuple and expression tuple (latter being instance
of former). Preserve auto-expansion. Provide two different
literals to remove ambiguity between referencing symbol as a
value and referencing it as an alias. Make compiler
auto-generate Tuple-like struct type for expression tuples that
need to be returned from functions. Create some new type in
std.typecons for those who don't want auto-expansion.
It won't even break stuff.
I think my position has changed to suggest nearly the same thing.
There needs to be a clear separation between built-in tuples and
tuple values. A runtime tuple literal syntax helps with that.
Making typeof(tuple(1, 2.3)) == TypeTuple!(int, double) helps as
well, because it is now clear that one is a value and one is a
type. Limiting the mixing of values and types within TypeTuple
helps with that.
This would allow both Tuple and TypeTuple to be deprecated. Tuple
wouldn't be needed anymore, because we would have a literal
syntax to replace it. It would only be there for backwards
compatibility. With Tuple deprecated, std.typetuple.TypeTuple
could be renamed Tuple, and we would then have only one thing
with the name Tuple in the language.
