Multiple return values...

[Manu]

On 15 March 2012 19:05, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> On 3/15/12 11:30 AM, Manu wrote:
>
>> On 15 March 2012 17:32, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail@**erdani.org<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?
>

Because now we're involving libraries to perform a trivial assignment.

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

That's fair, and in that case you might want to call such a function. But I
think that's very contrived.
I can't remember the last time I ever wanted to perform a swap on anything
other than stack primitives.
Also I think this (and perhaps more so MRV) will find a very major use case
in maths code, and maths code tends to revolve around simple (often single
letter) maths-y type variable names.

There's also semantic issues to be defined. What is the order of evaluation
> in
>
> f(), g() = h(), k();
>
> ?
>

Left to right, clearly. Keep it simple.

All of this adds dead weight to the language. We shouldn't reach to new
> syntax for every single little thing.


MRV is not 'every single little thing'. I'd say it's the single major
checklist item that D just doesn't tick (and perhaps user attributes,
although there's no resistance there, it's just not done yet).
I get the impression I'm not the only one here that feels that way too. I'm
perhaps just louder, and more annoying :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120315/df618d26/attachment-0001.html>