On 03/09/2012 04:38 PM, Manu wrote:
On 9 March 2012 16:27, Timon Gehr <[email protected]
<mailto:[email protected]>> wrote:

    On 03/09/2012 01:23 AM, Manu wrote:

        I can imagine syntax using parentheses, but I don't think I'm
        qualified
        to propose a robust syntax, I don't know enough about the finer
        details
        of the grammar.
        Perhaps if other people agree with me, they could present some
        creative
        solutions to the syntax?

        I imagine something like:
        auto (x, y) = func(); // specify auto for all results?
        float (x, y) = func(); // specify explicit type for all results?
        (int x, float y) = func; // explicitly type each result?


    This works, and Kenji Hara has already implemented appropriate
    parser extensions.

        int x; ... (x, float y) = func(); // assign to predeclared
        variable(/s)?
        (x, , z) = func(); // ignore the second result value
        (elimination of the

        second result's code path)


    Those two would work, but (x,y) = func(); conflicts with the comma
    operator. (I'd prefer (,) to be a tuple constructor though.)


You think so? Within that context, I would think the coma could be
reinterpreted however it likes. The usual use of the coma operator makes
no sense in this context?

void main(){
    int a,b;
    (a,b)=2;
    assert(a==0);
    assert(b==2);
}


These last 2 examples are what I see as being the most important part,
and the precise reason that it SHOULDN'T be a tuple.

You are probably confusing the tuple concept with a Phobos Tuple.

The ability to
directly assign results to explicit (existing) variables, and to ignore
some/all of the return values, is a fundamental feature of the /concept/
of return values universally.
I see this as basically the whole point.
Another example: (someStruct.x, y, , int err) = func();
In this example, I assign the x result to a struct, y assigns to some
existing local, we ignore z because we can (visually states our intent,
would be hidden through use of a tuple), and we declare an int to
capture a potential error in place.

This is simple pattern matching.

If we were abusing the tuple syntax, we would need additional lines
following the call to assign the rvalues out to their appropriate
places, which is unnecessary spaghetti.

What you propose is tuple syntax.


Reply via email to