Give Non-1 Iterators the Same Pre/Post Behavior as Value-1 Iterators

💡 Ideas
1

This seems to be a language inconsistency.

Current spec:

let a = 5
let b = a++
b == 5

let a = 5
let b = ++a
b == 6

This is a useful behavior. Why should only value-1 iterators enjoy it?

Here is a possible syntax for non-1 iterators. This syntax seems maybe good, because it's not an existing syntax. Currently, it would raise an error, so adding it to the language won't break anything. Also seems good because it's the same operator (++) as the value-1 pre/post operator.

// Pre: 
5 ++a,  or ++a 5

// Post: 
a++ 5

The following form shouldn't be used, because it's already in-use, and it's current behavior is (non-intuitively) prefix. Therefor, changing it to postfix would break existing code.
a += 5

2

Improved possible syntax:

// Pre: 
5++a

// Post: 
a++5
3

Here's why the pre- and post-increment operators exist: B → C → Java → JS, through little more than just pure cargo culting after the first step.

B likely had it due to hardware support (and compilers back then didn't really optimize much), and in C it was likely kept similarly for that but also for other general pointer arithmetic, but Java and JS would almost certainly not have them if they were designed today.

As for extending those operators, I see literally no benefit that provides that a += b doesn't.

1 Like
4

a += b doesn't give prefix behavior.

5

And what benefit does an expanded prefix allow?

I do also want to point out many languages don't even offer this, like Python and Rust. (Rust is about as low-level as C, so that's notable.) It's not like every language even has this.

6

Prefix returns the value before performing the addition.
Postfix returns the value after performing the addition.

Just a programmer convenience.

7

"Nice to have" isn't sufficient to merit inclusion into most languages with actual production usage. The issue is if you add enough "nice to have"s, it starts to become difficult to read as there's like 5-10 different ways to do the same thing. It also can result in unwanted runtime complexity - in fact, =='s coercing behavior is one of Brendan Eich's bigger regrets regarding JS, as he catered to a "nice to have" request. (It was initially what === is today, but people wanted to do stuff like status == 404 instead of status == "404", so he added it.) I also have first-hand experience with a language with so many blatant "nice to have"s, it's become difficult to use with parser bugs being historically fairly common.

8

Not just nice.
Also, "more consistent".
I'd say, in programming languages, consistency matters a LOT.

9

For consistency, the ++ and -- operators should be removed altogether in favour of the simple +=1/-=1, also removing the confusion around postfix vs prefix. But we all know that's not gonna happen.
Let's not make the language more complicated just for convenience in very rare cases.

2 Likes
10

"We all know that's not gonna happen" is a completely unproductive attitude. Your attitude is "Don't recommend things that you 'know' won't happen." That's irresponsible.

We don't "all know" what's going to happen with JS. Many changes have happened over time that we didn't "all know". It's inappropriate to second-guess what's "going to happen". You're silencing your own recommendations, and trying to silence others.

An appropriate, responsible, and forward-thinking design approach is:

  1. describe the best Javascript, in an ideal world, without second-guessing.
  2. Then prioritize, and determine what's practical.

You speak as if programmer convenience is really unimportant. I completely disagree. Programmer convenience is the reason any language exists.

What's "rare" for you might be common practice for another.

What "confusion"? If this use-case is as rare as you claim, then any confusion related to it will also be rare. Unless you're contradicting yourself.

Such confusion will be even more rare if programmers know what they're doing. Which they ought to, if they are calling themselves programmers.