C＃で==と！=の両方を定義する必要があるのはなぜですか？

C＃コンパイラでは、カスタム型がoperatorを定義する場合は常に==、それも定義する必要があります!=（ここを参照）。

どうして？

デザイナーがなぜそれを必要と考えたのか、そしてどちらか一方しか存在しない場合にコンパイラーがどちらかの演算子の妥当な実装をデフォルトにできないのか知りたいです。たとえば、Luaでは等値演算子のみを定義でき、もう1つは無料で取得できます。C＃は、==または==と！=の両方を定義して、不足している！=演算子をとして自動的にコンパイルするように要求することで、同じことを行うことができます!(left == right)。

（IEEE-754 NaNのように）一部のエンティティが等しくも等しくもない場合がある奇妙なコーナーケースがあることを理解していますが、それらは例外ではなく、規則のように見えます。したがって、これは、C＃コンパイラの設計者が例外をルールにした理由を説明していません。

等号演算子が定義されている仕上がりの悪さの例を見てきましたが、不等号演算子は、すべての比較が反転され、すべての&&が||に切り替えられたコピー/貼り付けです。（要点がわかります...基本的に！（a == b）は、ドモルガンのルールによって拡張されます）。これは、Luaの場合のように、コンパイラーが意図的に排除できるのは悪い習慣です。

注：演算子<> <=> =についても同様です。これらを不自然な方法で定義する必要がある場合は想像できません。Luaでは、前者の否定を通して、<と<=だけを定義し、> =と>を自然に定義できます。C＃が同じことをしないのはなぜですか（少なくとも「デフォルト」）。

編集

どうやらプログラマーが等しいかどうかのチェックを実装できるようにする正当な理由があるようです。いくつかの回答は、それが良い場合を示しています。

しかし、私の質問の核心は、通常これが論理的に必要ではないのに、なぜこれがC＃で強制的に要求されるのかということです。

またObject.Equals、のような.NETインターフェースの設計上の選択とは著しく対照的IEquatable.Equals IEqualityComparer.Equalsです。NotEquals対応するものがないため、フレームワークは!Equals()オブジェクトを不平等と見なし、それがそうです。さらに、のようなクラスDictionaryとメソッドのようなもの.Contains()は、前述のインターフェースにのみ依存しており、たとえ定義されていても、直接演算子を使用しません。実際、ReSharperが同等のメンバーを生成するとき、ReSharperは、ユーザーが演算子を生成することを選択した場合に限り、その両方の観点から、そしてその場合でも、両方==を定義します。オブジェクトの等価性を理解するために、フレームワークでは等価演算子は必要ありません。!=Equals()

基本的に、.NETフレームワークはこれらの演算子を考慮せず、いくつかのEqualsメソッドのみを考慮します。==と！=の両方の演算子をユーザーがタンデムで定義することを要求する決定は、.NETに関する限り、オブジェクトのセマンティクスではなく、純粋に言語設計に関連しています。

私は言語デザイナーのために話すことはできませんが、私が推論できることから、それは意図的で適切な設計決定であったようです。

この基本的なF＃コードを見ると、これを作業用ライブラリにコンパイルできます。これはF＃の正当なコードであり、不等式ではなく等号演算子のみをオーバーロードします。

module Module1

type Foo() =
    let mutable myInternalValue = 0
    member this.Prop
        with get () = myInternalValue
        and set (value) = myInternalValue <- value

    static member op_Equality (left : Foo, right : Foo) = left.Prop = right.Prop
    //static member op_Inequality (left : Foo, right : Foo) = left.Prop <> right.Prop

これはまさにそれがどのように見えるかを行います。等価比較器==のみを作成し、クラスの内部値が等しいかどうかを確認します。

このようなクラスはC＃では作成できませんが、.NET用にコンパイルされたクラスを使用できます。オーバーロードされた演算子を使用するのは明らかです。== つまり、ランタイムは何に使用し!=ますか？

C＃EMCA標準には、同等性を評価するときに使用する演算子を決定する方法を説明する一連の規則（セクション14.9）があります。単純化しすぎて完全に正確ではないようにするために、比較される型が同じ型であり、オーバーロードされた等価演算子が存在する場合、Objectから継承された標準の参照等価演算子ではなく、そのオーバーロードを使用します。したがって、演算子が1つしか存在しない場合、すべてのオブジェクトが持つデフォルトの参照等価演算子が使用され、オーバーロードがないことは驚くにあたりません。¹

これが事実であることを知って、本当の質問は次のとおりです。なぜこれがこのように設計されたのか、なぜコンパイラーはそれを自分で理解しないのですか？これは設計上の決定ではないと多くの人が言っていますが、特にすべてのオブジェクトにデフォルトの等価演算子があるという事実に関して、私はこのように考えられたと思います。

では、なぜコンパイラは自動的に!=演算子を作成しないのでしょうか？マイクロソフトの誰かがこれを確認しない限り、私は確実に知ることはできませんが、これは事実の推論から判断できるものです。

予期しない動作を防ぐため

おそらく、==同等性をテストするために値の比較を行いたいと思います。ただし、!=参照が等しくない限り、値が等しいかどうかはまったく気になりませんでした。これは、プログラムがそれらを等しいと見なすために、参照が一致するかどうかのみを気にするためです。結局のところ、これは実際にはC＃のデフォルトの動作として概説されています（別の言語で記述された.netライブラリの場合のように、両方の演算子がオーバーロードされなかった場合）。コンパイラーが自動的にコードを追加していた場合、準拠しているはずのコードを出力するためにコンパイラーに依存することができなくなりました。特に、作成したコードがC＃とCLIの両方の標準の範囲内にある場合、コンパイラーは、自分の動作を変更する非表示のコードを作成しないでください。

デフォルトの動作に行くのではなく、オーバーロードすることを強制するという点で、私はそれが標準（EMCA-334 17.9.2）^{2にあると}断言できます。規格はその理由を明記していません。これは、C＃がC ++から多くの動作を借用しているためだと思います。これについて詳しくは、以下を参照してください。

!=and をオーバーライドする場合==、boolを返す必要はありません。

これはもう1つの理由です。C＃では、この関数は：

public static int operator ==(MyClass a, MyClass b) { return 0; }

これと同じくらい有効です：

public static bool operator ==(MyClass a, MyClass b) { return true; }

bool以外のものを返す場合、コンパイラは反対の型を自動的に推測できません。さらに、オペレーターがブール値を返す場合、その特定のケースにのみ存在する生成コードを作成することや、前述のように、CLRのデフォルトの動作を非表示にするコードを作成しても意味がありません。

C＃はC ++ ³から多くを借りています

C＃が導入されたとき、CMSについて述べているMSDNマガジンの記事がありました。

多くの開発者は、Visual Basicのように記述、読み取り、保守が簡単で、しかもC ++の能力と柔軟性を備えた言語が存在することを望んでいます。

はい、C＃の設計目標は、C ++とほぼ同じ量のパワーを与えることでした。厳密な型の安全性やガベージコレクションなどの利便性のために少しだけ犠牲にしています。C＃はC ++に基づいて強くモデル化されました。

この例のプログラムに示すように、C ++では、等値演算子はboolを返す必要がないことを知って驚かないかもしれません

現在、C ++では、補完演算子をオーバーロードする必要はありません。サンプルプログラムでコードをコンパイルすると、エラーなしで実行されることがわかります。ただし、行を追加しようとした場合：

cout << (a != b);

あなたが得るでしょう

コンパイラエラーC2678（MSVC）：バイナリ '！='：タイプ 'Test'の左側のオペランドを取る演算子が見つかりません（または許容できる変換がありません） `。

C ++自体はペアでオーバーロードする必要はありませんしながら、そう、それはないでしょう、あなたがカスタムクラスにオーバーロードされていないことを等価演算子を使用してみましょう。すべてのオブジェクトにはデフォルトのオブジェクトがあるため、.NETでは有効です。C ++にはありません。

^{1.補足として、C＃標準では、どちらかの演算子をオーバーロードする場合は、演算子のペアをオーバーロードする必要があります。これは標準の一部であり、単なるコンパイラではありません。ただし、同じ要件を持たない別の言語で記述された.netライブラリにアクセスする場合、呼び出す演算子の決定に関する同じルールが適用されます。}

^{2. EMCA-334（pdf）（http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf）}

^{3.そしてJavaですが、それはここでは本当に重要ではありません}

おそらく誰かが3値論理（つまりnull）を実装する必要がある場合のために。このような場合-たとえばANSI標準SQL-入力によっては、演算子を単純に否定することはできません。

次のようなケースが考えられます。

var a = SomeObject();

そして、a == trueリターンfalseとa == falseも戻りますfalse。

C＃が多くの領域でC ++に依存していることを除けば、私が考えることができる最も良い説明は、「等しくない」を証明することと「等しくない」を証明することとでは少し異なるアプローチを取ることを望む場合があるということです。

たとえば、文字列比較を使用returnすると、一致しない文字が見つかったときに、等価性をテストしてループから外れるだけです。しかし、それはもっと複雑な問題でそれほどきれいではないかもしれません。ブルームフィルタは、頭に浮かぶ。それは要素がある場合はすぐに伝えることは非常に簡単ですではない要素があれば教えてセットではなく、困難であるセットに。同じreturnテクニックを適用できますが、コードはそれほどきれいではないかもしれません。

.netソースで==および！=のオーバーロードの実装を見ると、！=を！（left == right）として実装していないことがよくあります。彼らはそれを完全に（==のように）否定論理で実装します。たとえば、DateTimeは==を次のように実装します

return d1.InternalTicks == d2.InternalTicks;

そして！= as

return d1.InternalTicks != d2.InternalTicks;

あなた（またはそれを暗黙的に行った場合はコンパイラ）が！=を

return !(d1==d2);

次に、クラスが参照しているものの==および！=の内部実装について仮定します。その仮定を回避することが彼らの決定の背後にある哲学かもしれません。

あなたの編集に答えるために、一方をオーバーライドすると両方をオーバーライドする必要がある理由に関しては、すべて継承にあります。

==をオーバーライドすると、何らかの意味的または構造的な同等性が提供される可能性が最も高くなります（たとえば、InternalTicksプロパティが異なる場合でもDateTimesが等しい場合）、演算子のデフォルトの動作を変更します。すべての.NETオブジェクトの親であるオブジェクト。==演算子は、C＃ではメソッドであり、その基本実装Object.operator（==）は参照比較を実行します。Object.operator（！=）は、別の異なるメソッドであり、参照比較も実行します。

メソッドをオーバーライドする他のほとんどすべてのケースでは、1つのメソッドをオーバーライドすると、反則的なメソッドへの動作が変更されると推定することは不合理です。Increment（）およびDecrement（）メソッドを使用してクラスを作成し、子クラスでIncrement（）をオーバーライドした場合、オーバーライドされた動作の反対でDecrement（）もオーバーライドされることを期待しますか？可能性のあるすべての場合において、コンパイラーは、演算子の実装用の逆関数を生成するほどスマートにすることができません。

ただし、演​​算子はメソッドと非常によく似ていますが、概念的にはペアで機能します。==および！=、<および>、および<=および> =。この場合、！=が==とは異なる動作をすることを消費者の観点から考えるのは非論理的です。したがって、コンパイラーはすべてのケースでa！= b ==！（a == b）であると想定することはできませんが、==と！=は同じように動作するはずなので、コンパイラーはペアで実装する必要がありますが、実際にはそれを行うことになります。クラスの場合、a！= b ==！（a == b）の場合、！（==）を使用して！=演算子を実装するだけですが、そのルールがオブジェクトに対してすべての場合に適用されない場合（たとえば、等しいまたは等しくない特定の値との比較が無効な場合）、IDEよりも賢くする必要があります。

尋ねられるべきREALの質問は、<と>および<=と> =が比較演算子のペアであり、数値で表すと！（a <b）== a> = bと！（a> b）== a <= b。1つをオーバーライドする場合は4つすべてを実装する必要があり、==（および！=）もオーバーライドする必要がある可能性があります。 bに等しい。

！=ではなく、カスタムタイプの==をオーバーロードすると、すべてがオブジェクトから派生するため、オブジェクト！=オブジェクトの！=演算子によって処理されます。これは、CustomType！= CustomTypeとは大きく異なります。

また、言語の作成者はおそらく、この方法でプログラマーに最大の柔軟性を与えることを望んでおり、プログラマーが何をしようとしているのかを想定していません。

これが最初に頭に浮かぶものです。

• 不等式のテストが等式のテストよりもはるかに速い場合はどうなりますか？
• どのようないくつかのケースであれば、あなたが返すようにしたいfalseの両方を==して!=（つまり、彼らが何らかの理由で比較できない場合）

まあ、それはおそらく単なる設計上の選択ですが、あなたが言うx!= yように、と同じである必要はありません!(x == y)。デフォルトの実装を追加しないことにより、特定の実装を実装することを忘れることはできません。そして、それが本当にあなたの言うように取るに足りないものである場合は、一方をもう一方を使用して実装することができます。これが「練習不足」だとは思いません。

C＃とLuaの間にも他の違いがあるかもしれません...

あなたの質問のキーワードは、「なぜ」と「必ず」です。

結果として：

彼らがそうするように設計したので、このように答えるのは本当です...しかし、あなたの質問の「なぜ」の部分には答えません。

これらの両方を個別にオーバーライドすると役立つ場合があると答えることは事実ですが、質問の「必須」の部分には答えません。

簡単な答えは、C＃で両方をオーバーライドする必要があるという説得力のある理由はないということです。

言語はのみをオーバーライドできるようにし==、!=そのデフォルトの実装を提供する必要があります!。オーバーライドしたい場合は、それを試してください!=。

それは良い決断ではありませんでした。人間は言語を設計し、人間は完璧ではなく、C＃は完璧ではありません。肩をすくめてQED

ここで優れた答えに追加するだけです：

演算子にステップインして、代わりに演算子で終了しようとすると、デバッガーで何が起こるかを考えてください！混乱について話してください！!===

CLRを使用すると、多くの言語で機能する必要があるため、いずれかの演算子を自由に除外できるようになります。しかし、CLRを露出していないC＃の例がたくさんあります（特徴ref戻り、地元の人々 、例えば）、およびないCLR自体に機能を実装する例の多く（例：using、lock、foreach、など）。

プログラミング言語は、非常に複雑な論理ステートメントを構文的に再配置したものです。それを念頭に置いて、不平等のケースを定義せずに平等のケースを定義できますか？答えはノーだ。オブジェクトaがオブジェクトbと等しい場合、オブジェクトaの逆がbと等しくないことも真でなければなりません。これを示す別の方法は

if a == b then !(a != b)

これにより、言語がオブジェクトの同等性を決定する明確な機能が提供されます。たとえば、比較NULL！= NULLは、不等式ステートメントを実装しない等式システムの定義にレンチをスローする可能性があります。

ここで、！=の考えに関しては、単に次のように置き換え可能な定義である

if !(a==b) then a!=b

私はそれについて議論することはできません。ただし、プログラマーがオブジェクトの等価性と非等価性を一緒に明示的に定義することを余儀なくされたのは、おそらくC＃言語仕様グループによる決定でした

つまり、強制整合性です。

'=='と '！='は、「等しい」と「等しくない」の口頭による定義で定義されているため、どのように定義しても常に正反対です。それらの1つだけを定義することにより、与えられた2つの値に対して '=='と '！='の両方がtrueまたは両方ともfalseになる可能性がある等号演算子の不整合が発生します。どちらかを定義する必要があるので、どちらか一方を適切に定義して、「平等」の定義が露骨に明確になるようにする必要があります。コンパイラーのもう1つの解決策は、 '==' OR '！='のオーバーライドのみを許可し、他のものは本質的に他のものを無効にすることです。明らかに、C＃コンパイラではそうではなく、確かに

あなたが尋ねる必要がある質問は、「なぜ演算子をオーバーライドする必要があるのですか？」です。それは強い推論を必要とする強い決断です。オブジェクトの場合、「==」と「！=」は参照によって比較されます。参照によって比較しないようにそれらをオーバーライドする場合は、そのコードを熟読する他の開発者には明らかではない、一般的な演算子の不整合を作成しています。「これら2つのインスタンスの状態は同等ですか？」という質問をしようとしている場合は、IEquatibleを実装し、Equals（）を定義して、そのメソッド呼び出しを利用する必要があります。

最後に、IEquatable（）は、同じ理由でNotEquals（）を定義していません。等価演算子の不整合が生じる可能性があります。NotEquals（）は常に！Equals（）を返す必要があります。NotEquals（）の定義をEquals（）を実装するクラスに公開することにより、等価性の決定に一貫性の問題を再び強制することになります。

編集：これは単に私の推論です。

おそらく、彼らが思いもしなかった何かだけをする時間はありませんでした。

==をオーバーロードするときは、常にあなたのメソッドを使用します。それから私はそれを他のもので使用します。

ほんの少しの作業で、コンパイラはこれを無料で私たちに提供することができます。