Multiple return values...

[Manu]

On 9 March 2012 17:57, Timon Gehr <timon.gehr at gmx.ch> wrote:

> 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.


I'm not sure what you mean by this?


> 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.
>

What I mean is this:

retTuple = func();
someStruct.x = retTuple[0];
y = retTuple[1];
// retTuple[2] is ignored, but the intent is not clear in the code as it
was in my prior example, I like how my prior example makes this intent
explicit
int err = retTuple[3];

This is pretty horrible. Surely you can see why I want to be able to
arbitrarily assign the return values directly?
That's what I mean by 'abuse of the tuple syntax', but if that's not what
you mean, then show me an example of the usage of your suggestion?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120309/b6e9cb04/attachment.html>