2013/3/29 Timon Gehr <timon.gehr@gmx.ch>
Looks quite nice. I especially like the {a, b} => ... thing.

I think, however, that there are a handful serious flaws that need to be addressed:

0 "Inside tuple literal, ; never appears."
  {{;}}           // a tuple not matching your specification

It will be parsed as:
{     // tuple braces
    {;}   // function literal braces
}
 
  {{if(foo()){}}} // a non-tuple matching your specification

{    // tuple braces
    {    // function literal braces
        if (foo()){}   // "if" always appears in statement scope
    }
}
 
1 "Note: Cannot swap values by tuple assignment."
  IMO a no-go. The syntax is too accessible to introduce this kind of
  pitfall.

Allowing value swap in tuple assignment will make language complex. I can't agree with it.
 
2 "// Error: cannnot use $ inside a function literal"
  That's a DMD-ism presumably stemming from laziness during "fixing" of
  an ICE/wrong code bug or something. I'd hate to carry this over to
  the spec. Don't rely on it. The disambiguation is arbitrary, but may
  be necessary. (It's not like it is a case actually occurring in real
  code.)

3 Unpacking / pattern matching is underspecified.
  - Do patterns nest?

I think it should be allowed.
 
  - Which right-hand sides are allowed with which semantics?

Whether it is a pattern or a tuple-literal, is distinguished by their appeared locations.
 
  - Which left-hand sides are allowed with which semantics?
    eg, what about:
      ref int foo() { ... }
      { foo(), foo() } = {1, 2};

It will be lowered to:
// { foo(), foo() } = {1, 2};
foo() = 1;
foo() = 2;
 
4 There is no way to capture the part matched by "..."

I think this should be allowed.

auto {x, r...} = tup;
// Lowered to:
// auto x = tup[0];
// auto r = tup[1..$]

`...` is very consistent token for this purpose.

template X(T...) {}
alias x = X!(int, long);  // T captures {int, long}
 
5 .expand (or similar) property is missing.

Use tup[]. It is already exists.
 
6 Relation to {a: 2, b: 3}-style struct literals not explained.

I am skeptical of the necessity of tuple literal with named fields.

7 Tuple unpacking for template parameters not mentioned.


Is there a migration path for Phobos tuples planned?

Eg. template Tuple(T...){ alias Tuple = {T}; }
    (field spec parsing left out for illustration)

Kenji Hara