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

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?

• I'm incredibly perplexed that the %= operator even exists. Who decided that was necessary? Some of these operators seem like bad language design decisions. Mar 6, 2013 at 16:00
• @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. Mar 6, 2013 at 16:26
• @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?).
– user40980
Mar 6, 2013 at 17:35
• @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). Apr 21, 2013 at 9:41
• Note that in 2007 (someone claiming to be) Brendan Eich declared that `||=` and `&&=` would be coming soon: "You may be glad to learn that for JS2/ES4, ||= and &&= are being added as well. ||= is most useful of the two but there’s no reason to leave the assignment-op form of && out.". Jan 9, 2014 at 3:27

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.

• 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. Dec 26, 2016 at 2:03

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.

• 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 Mar 6, 2013 at 16:27
– user53019
Mar 7, 2013 at 11:53
• @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". Mar 7, 2013 at 14:00
• Note that typing `foo = foo || bar` requires you to type `foo` twice. This is both cumbersome and also prone to refactoring typos. Jan 9, 2014 at 3:29
• 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)` Dec 12, 2014 at 0:46

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.