なぜ論理演算子（||、&&など）の複合代入演算子がないのですか？

ECMA-262、パート11.13によると、複合割り当て演算子の完全なリストは次のとおりです*= /= %= += -= <<= >>= >>>= &= ^= |=。

パート11.11によると、var c = a || b置くaに値をc場合はToBoolean(a)trueで、入れますbに値をcそれ以外の場合は。そのため、論理ORは合体演算子としてよく使用されます。たとえば、

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

多くの場合、上記のように、合体を使用して変数のデフォルト値を指定しますa = a || b。

複合代入演算子||=は非常に便利で、上記のコードを短く簡潔に書くことができますa ||= b。ただし、そこにはありません（ただし*=、+=および他の複合代入演算子はあります）。

問題は、なぜですか？

考えられる理由の1つは、論理演算子&&と||「短絡」動作があることです。およびの右側のオペランドは&&、||必要でない限り評価されません。おそらくこの理由のために、言語設計者は式のような意味がa ||= f()明白ではないと判断し、そのような演算子は除外したほうがよいと判断しました。

「この言語機能が実装されなかった理由」に関するすべての質問に対する一般的な答えは、言語を設計したチームが、利益がコストを上回らないと判断したことです。

コストにはさまざまな形があります。言語機能を実装するには時間と労力がかかりますが、複雑さの本質的なコストもあります。機能は、潜在的な利点に比例して、言語をより複雑または曖昧にしますか？

仮想||=演算子は、他の複合代入演算子とは根本的に異なることを行います。他の演算子は純粋に数学的な性質を持っていますが、これは異なります（説明したコンテキストで）ある値を別の値に置き換えます。

この曖昧さ（演算子はコンテキストに応じて2つの異なる機能を実行します）を考えると、言語に含まれていない理由を見るのは難しくありません。あなたはその変化を述べていますが

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

に

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

nullの合体を実行することは価値のある機能ですが、その利点は私にはあまり明確ではありません。値の置換が発生する場合、等号の右側に両方の値があり、そのような置換が発生する可能性があることを視覚的に示すことが論理的（かつ明確）に思えます。

C＃は異なるパスを取り、null合体に特定の演算子を使用します。

あなたは正しい、それ||=は便利な構造です。Perlに存在します。

実際、Perlはこれらすべてを利用可能にします。

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

これらのいくつかは素晴らしい（.=文字列の最後に何かを追加する）、そうでない（&&=???それと変数の両方が真である場合、変数は右側に設定されると思います。しかし、なぜあなたはこれをするでしょうか？ ？）

言語に含まれるものは、実際にはその設計哲学の特徴です。