可能只是一些他们没有想到也没有时间去做的事情。

我总是用你的方法当我超载==。然后我把它用在另一个。

你是对的，只需少量的工作，编译器就可以免费提供给我们。

嗯，这可能只是一个设计选择，但如你所说，x!= y不一定和!(x == y)相同。通过不添加默认实现，您可以确定不会忘记实现特定的实现。如果它确实像你说的那样微不足道，你可以用一个实现另一个。我不明白这怎么是“糟糕的练习”。

c#和Lua之间可能还有一些其他的区别…

可能是为了如果有人需要实现三值逻辑(即null)。在这种情况下——例如，ANSI标准SQL——操作符不能简单地根据输入进行求反。

你可以有这样的情况:

var a = SomeObject();

a == true返回false, a == false也返回false。

除了c#在许多方面遵从c++之外，我能想到的最好的解释是，在某些情况下，你可能想要采取一种稍微不同的方法来证明“不相等”和证明“相等”。

显然，以字符串比较为例，您可以测试是否相等，并在看到不匹配的字符时返回循环。然而，对于更复杂的问题，它可能就不那么清晰了。我想到了bloom滤镜;快速判断元素是否在集合中非常容易，但判断元素是否在集合中非常困难。虽然可以应用相同的返回技术，但代码可能没有那么漂亮。

如果你看一下。net源代码中==和!=重载的实现，它们通常不会实现!= as !(左==右)。他们用否定的逻辑完全实现它(比如==)。例如，DateTime实现了== as

return d1.InternalTicks == d2.InternalTicks;

And != as

return d1.InternalTicks != d2.InternalTicks;

如果你(或编译器，如果它隐式地做)要实现!= as

return !(d1==d2);

然后，您要对类引用的对象中==和!=的内部实现做一个假设。避免这种假设可能是他们决定背后的哲学。

编程语言是对异常复杂的逻辑语句的语法重排。考虑到这一点，你能定义一个相等的情况而不定义一个不相等的情况吗?答案是否定的。如果一个物体a等于物体b，那么物体a的逆不等于b也必须成立。另一种表达方式是

如果a == b那么!(a != b)

这为语言确定对象的相等性提供了明确的能力。例如，比较NULL != NULL可能会对没有实现非相等语句的相等系统的定义产生不利影响。

现在，关于!=简单地是可替换的定义

如果!(a==b)那么a!= b

我不能反驳这一点。然而，这很可能是c#语言规范组的决定，程序员被迫显式地定义对象的相等性和非相等性

如果你为你的自定义类型重载==，而不是!=，那么它将由object != object的!=操作符处理，因为所有东西都是从object派生的，这将与CustomType != CustomType有很大不同。

此外，语言的创造者可能希望这种方式为编码员提供最大的灵活性，也这样他们就不会对你打算做什么做假设。

这是我首先想到的:

如果测试不平等比测试平等快得多呢? 如果在某些情况下，你想同时返回false for ==和!=(也就是说，如果它们由于某种原因不能进行比较)

你问题中的关键词是“为什么”和“必须”。

结果是:

这样回答是因为他们设计了这样，这是真的……但不回答你的"为什么"

回答说，有时独立地覆盖这两个可能是有帮助的，是真的…但没有回答你"必须"的问题。

我认为简单的答案是，c#没有任何令人信服的理由要求你重写这两者。

该语言应该只允许您重写==，并为您提供一个默认的!=实现，即!那如果你碰巧也想重写!=，那就试试吧。

这不是一个好的决定。人类设计语言，人类并不完美，c#也不完美。耸耸肩，回答问题

我不能代表语言设计师说话，但从我的推理来看，这似乎是有意为之，合理的设计决策。

看看这个基本的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编译的类。很明显，它将使用重载操作符for ==那么，运行时使用什么!=?

The C# EMCA standard has a whole bunch of rules (section 14.9) explaining how to determine which operator to use when evaluating equality. To put it overly-simplified and thus not perfectly accurate, if the types that are being compared are of the same type and there is an overloaded equality operator present, it will use that overload and not the standard reference equality operator inherited from Object. It is no surprise, then, that if only one of the operators is present, it will use the default reference equality operator, that all objects have, there is not an overload for it.1

知道了这种情况后，真正的问题是:为什么要这样设计，为什么编译器不自己解决这个问题?很多人都说这不是一个设计决策，但我喜欢这样认为，特别是考虑到所有对象都有一个默认的相等运算符。

那么，为什么编译器不自动创建!=操作符呢?我不能确定，除非微软的人证实这一点，但这是我可以从事实推理得出的结论。

---

防止意外行为

Perhaps I want to do a value comparison on == to test equality. However, when it came to != I didn't care at all if the values were equal unless the reference was equal, because for my program to consider them equal, I only care if the references match. After all, this is actually outlined as default behavior of the C# (if both operators were not overloaded, as would be in case of some .net libraries written in another language). If the compiler was adding in code automatically, I could no longer rely on the compiler to output code that should is compliant. The compiler should not write hidden code that changes the behavior of yours, especially when the code you've written is within standards of both C# and the CLI.

至于它迫使你重载它，而不是去默认的行为，我只能坚定地说，它是在标准(EMCA-334 17.9.2)2。该标准没有具体说明原因。我相信这是因为c#从c++中借鉴了很多行为。有关这方面的更多信息，请参见下文。

---

当你重写!=和==时，你不必返回bool。

这是另一个可能的原因。在c#中，这个函数:

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

和这个一样有效

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

如果返回的不是bool类型，编译器就不能自动推断出相反的类型。此外，在你的操作符确实返回bool值的情况下，创建只存在于特定情况下的生成代码没有意义，或者像我上面说的，隐藏CLR默认行为的代码。

---

c#大量借鉴了c++ 3

当c#被引入时，在MSDN杂志上有一篇文章是这样谈论c#的:

许多开发人员希望有一种像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，但这不是重点

要回答您的编辑，关于为什么如果您覆盖了一个，就必须覆盖两个，这都在继承中。

If you override ==, most likely to provide some sort of semantic or structural equality (for instance, DateTimes are equal if their InternalTicks properties are equal even through they may be different instances), then you are changing the default behavior of the operator from Object, which is the parent of all .NET objects. The == operator is, in C#, a method, whose base implementation Object.operator(==) performs a referential comparison. Object.operator(!=) is another, different method, which also performs a referential comparison.

In almost any other case of method overriding, it would be illogical to presume that overriding one method would also result in a behavioral change to an antonymic method. If you created a class with Increment() and Decrement() methods, and overrode Increment() in a child class, would you expect Decrement() to also be overridden with the opposite of your overridden behavior? The compiler can't be made smart enough to generate an inverse function for any implementation of an operator in all possible cases.

However, operators, though implemented very similarly to methods, conceptually work in pairs; == and !=, < and >, and <= and >=. It would be illogical in this case from the standpoint of a consumer to think that != worked any differently than ==. So, the compiler can't be made to assume that a!=b == !(a==b) in all cases, but it's generally expected that == and != should operate in a similar fashion, so the compiler forces you to implement in pairs, however you actually end up doing that. If, for your class, a!=b == !(a==b), then simply implement the != operator using !(==), but if that rule does not hold in all cases for your object (for instance, if comparison with a particular value, equal or unequal, is not valid), then you have to be smarter than the IDE.

真正的问题应该问是为什么<、>、< =和> =是对比较操作符必须同时实现,当在数值上! (b < b) = = > =和! (a > b) = = < = b。你应该需要实现所有四个如果你覆盖,你应该需要重写= =(和! =),因为(< = b) = = (a = = b)如果一个语义等于b。

在这里补充一下精彩的答案:

考虑一下在调试器中会发生什么情况，当您试图进入!=操作符而最终进入==操作符时!真让人困惑!

CLR允许您自由地省略一个或另一个操作符，这是有道理的——因为它必须与许多语言一起工作。但是有很多c#不公开CLR特性的例子(例如，ref returns和locals)，也有很多实现CLR本身之外的特性的例子(例如:using, lock, foreach等)。

简而言之，强迫一致性。

'==' and '!=' are always true opposites, no matter how you define them, defined as such by their verbal definition of "equals" and "not equals." By only defining one of them, you open yourself up to an equality operator inconsistency where both '==' and '!=' can both be true or both be false for two given values. You must define both since when you elect to define one, you must also define the other appropriately so that it is blatantly clear what your definition of "equality" is. The other solution for the compiler is to only allow you to override '==' OR '!=' and leave the other as inherently negating the other. Obviously, that isn't the case with the C# compiler and I'm sure there's a valid reason for that that may be attributable strictly as a choice of simplicity.

The question you should be asking is "why do I need to override the operators?" That is a strong decision to make which requires strong reasoning. For objects, '==' and '!=' compare by reference. If you are to override them to NOT compare by reference, you are creating a general operator inconsistency that is not apparent to any other developer who would peruse that code. If you are attempting to ask the question "is the state of these two instances equivalent?," then you should implement IEquatible, define Equals() and utilize that method call.

最后，由于同样的原因，IEquatable()没有定义NotEquals():可能会导致相等运算符不一致。NotEquals()应该总是返回!通过将NotEquals()的定义开放给实现Equals()的类，您再次迫使确定相等性的一致性问题。

编辑:这只是我的理由。