A Discussion of Tuple Syntax

[Meta]

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.