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