Why there are no compound assignment operators for logical operators (such as ||, && etc)?

Question

According to ECMA-262, part 11.13, following is the exhaustive list of compound assignment operators: *= /= %= += -= <<= >>= >>>= &= ^= |=.

According to the part 11.11, var c = a || b will put a value into c if ToBoolean(a) is true and will put b value into c otherwise. As such, the logical OR is often used as the coalesce operator, e.g.

function (options) {
 options = options || {};
}

Frequently enough, coalesce is used to specify the default value for the variable, as was shown above: a = a || b.

It seems that compound assignment operator ||= would be really useful, allowing to write the code above in a shorter and cleaner fashion: a ||= b. However, it is not there (although *=, += and other compound assignment operators are).

The question is, why?

• Jonathan Rich: I'm incredibly perplexed that the %= operator even exists. Who decided that was necessary? Some of these operators seem like bad language design decisions.
• kevin cline: @JonathanRich: why not have %= ? If you are going to have any of these assignment operators, sooner or later some developer (like penartur) will wonder why operators are "more equal" than others.
• user40980: @JonathanRich Crypto makes significant use of modulus. Furthemore, there is a desired orthogonality with the rest of the arithmetic to arithmetic assignment operators (if one expects +=, *=, -=, /=, why wouldn't %= work?).
• Sebastian Negraszus: @JonathanRich: The operator comes in handy when you have something circular and want to normalize it, e.g. angle %= 360 or vertexIndex %= numberOfVertices (for the vertex list of a closed polygon).
• Steve Summit: @JonathanRich: I used %= just last week, without even thinking about it. And I see two uses in the tzcode distribution from twinsun.com/tz/tz-link.htm: tmp->tm_wday %= DAYSPERWEEK; and rem %= SECSPERHOUR. In both cases, as Sebastian Negraszus suggested, a quantity (which might have overflowed) is being reduced to its proper range (0-6 or 0-59 in these cases).

Answer 1

One possible reason is that the logical operators && and || have "short-circuiting" behavior. The right-hand operand of && and || is not evaluated unless necessary. Perhaps for this reason the language designers decided that the meaning of an expression like a ||= f() was not obvious, and so such operators were better left out.

• Franklin Yu: Yes. For example, many people believe that a ||= b should be interpreted as a = a || b, but actually it can be a || a = b (like in Ruby). They may be different if the setter have side effect. Choosing one may be bad for users in the other camp. I personally like the a || a = b way (the Ruby way), but I am not sure whether everyone is happy with that.
• Caleth: @FranklinYu Or you have the caveat'd "a ||= b is equivalent to <either>, except that a is only evaluated once"

Answer 2

The general answer to all questions about "why was this language feature not implemented" is that the team who designed the language decided that the benefit didn't outweigh the cost.

Cost can take many forms. It takes time and effort to implement a language feature, but there is also the intrinsic cost of complexity: does the feature make the language more complex or ambiguous, out of proportion to its potential benefit?

The hypothetical ||= operator does something fundamentally different from the other compound assignment operators. While the other operators are purely mathematical in nature, this one is different: it substitutes one value for another (in the context you described).

Given this ambiguity (the operator performs two different functions, depending on context), it's not difficult to see why it was not included in the language. Although you state that changing

function (options) {
 options = options || {};
}

to

function (options) {
 options ||= {};
}

to perform null coalescing is a valuable feature, the benefit is far less clear to me. If value substitution is to occur, it seems logical (and clearer) to have both values on the right side of the equals sign, to provide a visual indication that such substitution may occur.

C# took a different path, and uses a specific operator for null coalescing.

• Andy Hunt: When reading the code, the first example there reads more naturally - "options equals options or nothing" - compared to the second - "options or equals nothing". I think this is just another reason for not including the "or equals" operator
• user53019: Excellent opening to your answer. And I think the beginning of your answer belongs within the wiki for the tag.
• penartur: @AndyBursh The same logic could be applied to any compound assignment operator. "X equals X times 2" reads more naturally compared to the "X times equals 2".
• Phrogz: Note that typing foo = foo || bar requires you to type foo twice. This is both cumbersome and also prone to refactoring typos.
• joshperry: I think you misunderstand the meaning of "mathematical", perhaps you have heard of boolean algebra. I agree the coercing a non-boolean in order to use ||= as a null coalescing operator is not intuitive and in fact looks obtuse in code-form. Where it does become useful is when you are attempting to do boolean math. function fulfill(inValue) { if(resolved || rejected) return false; /* Do stuff here */ return true; } resolved ||= fulfill(value)

Answer 3

You are right that ||= is a useful construct. It exists in Perl.

In fact Perl makes all of these available:

**= += *= &= <<= &&= -= /= 
|= >>= ||= .= %= ^= //= x=

Some of these are great (.= adds something to the end of a string), others less so (&&=??? I suppose the variable would get set to the right side if both it and the variable are true. But why would you ever do this?)

What is included in a language is really a feature of its design philosophy.

• Mat: stackoverflow.com/questions/12589467/… for what &&= means/does.

Answer 4

The question is, why?

Because it was not designed and implemented yet.

As of ECMAScript 2021 ||= is a valid assignment alongside =, **=, *=, /=, %=, +=, -=, <<=, >>=, >>>=, &=, ^=, |=, &&=, and ??=.

The omission of the logical assignments was not because somebody sat down and said "We need these ones but will most definitely not be including those ones and This Is How The Language Is To Be". Rather, it takes time and effort to add each language feature. If that time and effort is not put in or not enough, you do not get the language feature.

The explanation seems underwhelming but it is what it is. Programming languages are most often held back by human limitations to how much time and effort they have, rather than the humans deliberately imposing limitation on what a programming language should be able to do.