DIP32: Uniform tuple syntax
kenji hara
k.hara.pg at gmail.com
Fri Mar 29 09:03:02 PDT 2013
2013/3/30 Timon Gehr <timon.gehr at gmx.ch>
> On 03/29/2013 04:32 PM, kenji hara wrote:
>
>> 2013/3/29 Timon Gehr <timon.gehr at gmx.ch <mailto:timon.gehr at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130330/d541a30c/attachment-0001.html>
More information about the Digitalmars-d
mailing list