Multiple return values...

[Manu]

On 9 March 2012 16:27, Timon Gehr <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?

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. 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120309/f4477b0b/attachment.html>