This is exactly why I hate such C-style syntactic sugar as pseudo-atomic “function plus side effect” operators. Especially their prefix versions “copy the original_value somewhere; copy it once again, increment and store back; use the old copy of original_value as the result”.
Consider for(;;i++) versus for(;;++i). It is not obvious at all whether the actual modification of i actually occurs at the start of the loop body (where it is written) or at the end. What about for(;i++>n;) / for(;++i>n;) ?
It is confusing at least, and seemingly has been created for the sole reason of brevity of loop expressions. Where other languages have “for(i : 0..n-1)...”, in a C-style language you should repeat yourself as in “for(i=0;i<n;i++)...”.
Otherwise why do we have ++ and --, but no !!, **, //, &&&&, ||||, <<<<, >>>>, >>>>>>?
That given, I still consider modify-and-assign-back operators (i+=1, i*=2, i>>=1, etc.) a very valuable syntactic shorthand for inc(i,1), shr(i,1) as in other languages e.g. Pascal, and yet they still have some ambiguity such as in “x^=y^=x^=y”. A novice might expect that ^= is an atomic operator and this expression is a perfectly legal XOR-swapping.
Unfortunately, the consensus among modern languages is exactly the opposite: every variable is loaded just once before evaluating the expression, and their temporary changes are lost.
Now consider a language such as C# where += is overloaded for a collection type as .add(value) or .addAll(collection). What would be the semantics of “col+=col+=col”?
I think that operations such as “increment and assign” should have been defined as statements, not expressions – i.e. to return a void value and be forbidden to be nested into larger expressions.
This way you could still write something along the lines of “while(i-=1,i>0)” without any ambiguities.
While the compilers allow such ambiguous compound expressions, I feel that they should be explicitly forbidden at least in code style guides.
As a side note, the = character is also the reason why I feel that the syntax of lambda expressions in ES6 ( x=>x+1 ) is much more confusing than in Java ( x->x+1 ). The double arrow intuitively implies a definition or an assignment back to the parameter list, while the single arrow reminds the mathematical notation of mapping.
Unfortunately in C++ and PHP the single arrow operator was already defined as a dereference of a struct member, so we have double arrows in C++ and, by copying, in ES6 (but frankly not in PHP7). Actually, in PHP the double arrow is exactly the definition and assignment of associative array's member (and mapping keys to values), and I don't see the reason PHP should introduce a shorthand syntax for anonymous functions (a sugar for function(){} syntax like in ES5).
Perhaps ES6 shouldn't have either – in my personal opinion, Firefox 3.6 had a better solution, that it allowed just to write a return expression instead of a function body (without curly braces and an explicit return keyword):
var f = function(x)x+1; [0,1,2].map(f); // returns [1,2,3]
You could define lambdas almost just as concisely but without any special keywords or operators.
This shows that not only novices, but experienced language designers too are prone to inventing unnecessary cryptic operators.
This is exactly why I hate such C-style syntactic sugar as pseudo-atomic “function plus side effect” operators. Especially their prefix versions “copy the original_value somewhere; copy it once again, increment and store back; use the old copy of original_value as the result”.
Consider
for(;;i++)versusfor(;;++i). It is not obvious at all whether the actual modification ofiactually occurs at the start of the loop body (where it is written) or at the end. What aboutfor(;i++>n;)/for(;++i>n;)?It is confusing at least, and seemingly has been created for the sole reason of brevity of loop expressions. Where other languages have “
for(i : 0..n-1)...”, in a C-style language you should repeat yourself as in “for(i=0;i<n;i++)...”.Otherwise why do we have
++and--, but no!!,**,//,&&&&,||||,<<<<,>>>>,>>>>>>?That given, I still consider modify-and-assign-back operators (
i+=1, i*=2, i>>=1, etc.) a very valuable syntactic shorthand forinc(i,1),shr(i,1)as in other languages e.g. Pascal, and yet they still have some ambiguity such as in “x^=y^=x^=y”. A novice might expect that^=is an atomic operator and this expression is a perfectly legal XOR-swapping.Unfortunately, the consensus among modern languages is exactly the opposite: every variable is loaded just once before evaluating the expression, and their temporary changes are lost.
Now consider a language such as C# where
+=is overloaded for a collection type as.add(value)or.addAll(collection). What would be the semantics of “col+=col+=col”?I think that operations such as “increment and assign” should have been defined as statements, not expressions – i.e. to return a
voidvalue and be forbidden to be nested into larger expressions.This way you could still write something along the lines of “
while(i-=1,i>0)” without any ambiguities.While the compilers allow such ambiguous compound expressions, I feel that they should be explicitly forbidden at least in code style guides.
As a side note, the = character is also the reason why I feel that the syntax of lambda expressions in ES6 (
x=>x+1) is much more confusing than in Java (x->x+1). The double arrow intuitively implies a definition or an assignment back to the parameter list, while the single arrow reminds the mathematical notation of mapping.Unfortunately in C++ and PHP the single arrow operator was already defined as a dereference of a struct member, so we have double arrows in C++ and, by copying, in ES6 (but frankly not in PHP7). Actually, in PHP the double arrow is exactly the definition and assignment of associative array's member (and mapping keys to values), and I don't see the reason PHP should introduce a shorthand syntax for anonymous functions (a sugar for
function(){}syntax like in ES5).Perhaps ES6 shouldn't have either – in my personal opinion, Firefox 3.6 had a better solution, that it allowed just to write a return expression instead of a function body (without curly braces and an explicit return keyword):
var f = function(x)x+1; [0,1,2].map(f); // returns [1,2,3]
You could define lambdas almost just as concisely but without any special keywords or operators.
This shows that not only novices, but experienced language designers too are prone to inventing unnecessary cryptic operators.
I like your take on this. It's very thought-provoking. These operators truly are one of the sources of evil in C-like languages.