That is just a bad idea.

There really is no such thing as a "Long arrow" operator.

The example of:

while (i --> 0) {
  console.log(pets[i]);
}

Is really just:

while (i-- > 0) {
  console.log(pets[i]);
}

The post decrement does not belong to the greater than sign, and implies entirely different things.

seems like an excellent way to frustrate the hell out of future maintainers. the formatting is weird and the value you declared for your index is never used. that's subtle and unexpected (two things you should never be striving for in code meant to be read by humans).

TL;DR: x --> 0 = x-- > 0

In 12 years of the programming, I first hear about "long arrow" operator. It confuses beginners.
But you can do the same, in easy way:

let x = 2
while (x--) { 
  console.log(x)
} 
// 1
// 0

Looks beautiful with my font ligatures!

Oh, what's that? A reverse long-arrow operator? Read about it here!

That's why everyone should avoid increment (++) and decrement (--) operators

As in the Douglas Crockford's Javascript: The Good Parts, he writes:

++ and --
The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by
encouraging excessive trickiness. They are second only to faulty architecture in enabling to viruses and other security menaces. There is a plusplus option [in JSLint] that prohibits the use of these 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++) 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.

Creative! I love weirdness like this.

The only problem with it is that it requires reeducation. And people really resist being educated.

Perfect for a pet project. Not so much for your employer's source.

You'd just have to add some docs to explain what this funky thing does.

Cheers!

This article is a much needed resource for someone who might come across such usage and google it. I agree that it shouldn't be used because it relies on whitespace formatting and in fact, deceives the reader into thinking it's a single legitimate operator.

I suggest adding names of languages that accept this usage in the title? And perhaps a clarification in the beginning that the "long arrow operator" doesn't actually exist.

Note that in every modern browser “the Robin Hood operator” is actually considered a start of a single – line comment if it occurs at the start of the line or is preceded only by whitespace.

So if you accidentally put an EOL after “x”, that code becomes illegal.

OTOH, it is possible to hide some malicious hidden/polyglot code behind the --> operator.

stackoverflow.com/questions/578004...