Multiple return values...

[Timon Gehr]

On 03/09/2012 04:38 PM, Manu wrote:
> On 9 March 2012 16:27, Timon Gehr <timon.gehr at gmx.ch
> <mailto:timon.gehr at gmx.ch>> 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.