DIP32: Uniform tuple syntax
kenji hara
k.hara.pg at gmail.com
Fri Mar 29 08:32:35 PDT 2013
2013/3/29 Timon Gehr <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
{;} // 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130330/17d0469d/attachment.html>
More information about the Digitalmars-d
mailing list