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
