Multiple return values...

[Andrei Alexandrescu]

On 3/15/12 12:51 PM, Manu wrote:
> On 15 March 2012 19:05, Andrei Alexandrescu
>     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 not a trivial assignment, it's swapping two pieces of data. This 
matter has aliasing and ordering implications. Most languages don't make 
swapping a primitive.

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

How is it contrived? I can't figure for the life of me how "to swap a 
and b call swap(a, b)" is contrived. I mean swapping is even _called_ swap.

So if I can name it as a function and with a suggestive name, and if the 
function is useful, why do we _also_ need a special syntax?

> I can't remember the last time I ever wanted to perform a swap on
> anything other than stack primitives.

I think that's an exaggeration. swap() is very often (almost always?) 
called with expressions, see e.g. std.algorithm.

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

I am confident your math code will not look any worse with swap(a, b).

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

Problem is, that and the related issues need to go in the manual.

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

This discussion is about swap.

> 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 understand how the draw of reaching for new syntax is extremely 
alluring. I used to fall for it much more often, but over years I have 
hardened myself to resist it, and I think that made me a better language 
designer. In this stage of D, I think we should all have an 
understanding that adding syntax is not a win. Instead, it is an 
acknowledgment that the existing language, for all its might, is unable 
to express the desired abstraction. This is sometimes fine (such as in 
the case of introducing multiple new symbols from one tuple), but 
generally the question is not "why couldn't we add syntax X?" but 
instead "why should we add syntax X?"


Andrei