2013/3/30 Timon Gehr <timon.gehr@gmx.ch>
On 03/29/2013 04:32 PM, kenji hara wrote:
2013/3/29 Timon Gehr <timon.gehr@gmx.ch <mailto:timon.gehr@gmx.ch>>
It will be parsed as:
{     // tuple braces

It contains ';', therefore the DIP says it is a function literal brace.

     {;}   // function literal braces

}

       {{if(foo()){}}} // a non-tuple matching your specification


{    // tuple braces
     {    // function literal braces

There is no ';', therefore the DIP says it is a tuple brace.


         if (foo()){}   // "if" always appears in statement scope
     }
}


I know how it _should_ be. The DIP contradicts what you say.

Sorry my incomplete description and poor English. I'll improve description in DIP.
  
Allowing value swap in tuple assignment will make language complex. I
can't agree with it.

Quite obviously it is the other way round. There will be a never-ending flood of d.D.learn posts on the topic.

Yes, I agree with it. But, I won't change my opinion. So I'll stop talking about that.
 
       - Which right-hand sides are allowed with which semantics?


Whether it is a pattern or a tuple-literal, is distinguished by their
appeared locations.

Obviously, but this statement is not related to my question.
Valid right-hand sides seem to be at least tuples and expanded tuples (sequences). Anything else?

Sorry I don't understand you question.

    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.

Questionable.

template X(T...) {}
alias x = X!(int, long);  // T captures {int, long}


Not really. T captures {int, long}.expand.

    5 .expand (or similar) property is missing.


Use tup[]. It is already exists.

Slicing obviously shouldn't auto-expand. It's a shortcoming of the Phobos tuple introduced because static slicing cannot be overloaded.

I think it will become reasonable. If you really want re-packing tuple, you can use {tup[0..1]}. It's quite handy.

    6 Relation to {a: 2, b: 3}-style struct literals not explained.


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


Sure, but you'd at least have to argue in the DIP that the parser can distinguish the two, and how.

    7 Tuple unpacking for template parameters not mentioned.

Will add description about it. 

    Is there a migration path for Phobos tuples planned?

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

I have no plan.

Kenji Hara