DIP32: Uniform tuple syntax
Timon Gehr
timon.gehr at gmx.ch
Fri Mar 29 08:47:51 PDT 2013
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>>
>
> 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
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.
> 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.
>
Quite obviously it is the other way round. There will be a never-ending
flood of d.D.learn posts on the topic.
> 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.
>
ok.
> - 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?
> - 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;
>
ok.
> 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.
> 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.
>
>
> Is there a migration path for Phobos tuples planned?
>
> Eg. template Tuple(T...){ alias Tuple = {T}; }
> (field spec parsing left out for illustration)
>
>...
You have not answered the last two points.
More information about the Digitalmars-d
mailing list