On 03/29/2013 04:32 PM, kenji hara wrote:
2013/3/29 Timon Gehr <[email protected] <mailto:[email protected]>>
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.
