Multiple return values...

[foobar]

On Thursday, 15 March 2012 at 17:05:00 UTC, Andrei Alexandrescu 
wrote:
> On 3/15/12 11:30 AM, Manu wrote:
>> On 15 March 2012 17:32, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org 
>> <mailto:SeeWebsiteForEmail at erdani.org>>
>> wrote:
>>    One note - the code is really ingenious, but I still prefer 
>> swap()
>>    in this case. It's more concise and does less work in the 
>> general case.
>>
>>    swap(a[i + k], a[j + j]);
>>
>>    only computes the indexing once (in source, too).
>>
>>
>> It all still feels to me like a generally ugly hack around the 
>> original
>> example:
>>   a,b = b,a;
>
> It's a function call. Why is a function call a ugly hack?
>
> It's also more verbose. Compare
>
> swap(a[i + k], a[i + j]);
>
> with
>
> a[i + k], a[i + j] = a[i + j], a[i + k];
>
> I mean one could even easily miss a typo in there.
>
> There's also semantic issues to be defined. What is the order 
> of evaluation in
>
> f(), g() = h(), k();
>
> ?
>
> All of this adds dead weight to the language. We shouldn't 
> reach to new syntax for every single little thing.
>
>
> Andrei

even if swap is preferable here (IMO the syntax improvement here 
is negligible) it is still a special case. In the general case 
Ruby allows e.g:
a, b, c, d = b, d, a, c

How would you do this with swap?

The order of evaluation is an orthogonal issue to the syntax.
The compiler calculates n functions to produce n values so we 
could leave the order undefined.

Some FP languages define order of evaluation (e.g. left to right) 
but IMO this is more suitable for older PCs with serial execution 
(single processor). It's worth considering for current and future 
multi/many-core PCs to instead evaluate the tuple concurrently. 
or perhaps provide both options, e.g.
f(), g() // left to right
@parallel f(), g() // separate tasks/threads

Or perhaps even switch the default to make the parallel order the 
default and mark the former with a @serial annotation.