A Discussion of Tuple Syntax

[Dicebot]

On Tuesday, 20 August 2013 at 13:17:44 UTC, Meta wrote:
> This is the reason I had originally thought Kenji's DIP was 
> about run-time tuples. If it's just syntactic sugar over 
> std.typecons.Tuple (plus some extra destructuring/pattern 
> matching stuff), it would require no ABI changes and no changes 
> to TypeTuple semantics. The one thing it wouldn't do is unify 
> Tuple and TypeTuple.

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.

> However, with compiler support, we can make this situation 
> better. TypeTuple stays as-is, while Tuple becomes a value 
> instead of a type, which has its own literal syntax. This means 
> that typeof(tuple(1, "a")) is not Tuple!(int, string), as in 
> the struct, but TypeTuple!(int, string), as in the compiler 
> tuple.

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.