Why must we define both == and != in C#?

Question

The C# compiler requires that whenever a custom type defines operator ==, it must also define != (see here).

Why?

I\'m curious to k

Answer 1

In short, forced consistency.

'==' 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.

Lastly, IEquatable() does not define NotEquals() for the same reasoning: potential to open up equality operator inconsistencies. NotEquals() should ALWAYS return !Equals(). By opening up the definition of of NotEquals() to the class implementing Equals(), you are once again forcing the issue of consistency in determining equality.

Edit: This is simply my reasoning.

Answer 2

This is what comes to my mind first:

• What if testing inequality is much faster than testing equality?
• What if in some cases you want to return false both for == and != (i.e. if they can't be compared for some reason)

Answer 3

Programming languages are syntactical rearrangements of exceptionally complex logical statement. With that in mind, can you define a case of equality without defining a case of non-equality? The answer is no. For an object a to be equal to object b, then the inverse of object a does not equal b must also be true. Another way to show this is

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

this provides the definite ability for the language to determine the equality of objects. For instance, the comparison NULL != NULL can throw a wrench into the definition of a equality system that does not implement a non-equality statement.

Now, in regards to the idea of != simply being replaceable definition as in

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

I can't argue with that. However, it was most likely a decision by the C# language specification group that the programmer be forced to explicitly define the equality and and non-equality of an object together

Answer 4

To answer your edit, regarding why you are forced to override both if you override one, it's all in the inheritance.

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.

The REAL question that should be asked is why < and > and <= and >= are pairs for comparative operators that must be implemented concurrently, when in numeric terms !(a < b) == a >= b and !(a > b) == a <= b. You should be required to implement all four if you override one, and you should probably be required to override == (and !=) as well, because (a <= b) == (a == b) if a is semantically equal to b.

Answer 5

Well, it's probably just a design choice, but as you say, x!= y doesn't have to be the same as !(x == y). By not adding a default implementation, you are certain that you cannot forget to implement a specific implementation. And if it's indeed as trivial as you say, you can just implement one using the other. I don't see how this is 'poor practise'.

There may be some other differences between C# and Lua too...

Answer 6

The key words in your question are "why" and "must".

As a result:

Answering it's this way because they designed it to be so, is true ... but not answering the "why" part of your question.

Answering that it might sometimes be helpful to override both of these independently, is true ... but not answering the "must" part of your question.

I think the simple answer is that there isn't any convincing reason why C# requires you to override both.

The language should allow you to override only ==, and provide you a default implementation of != that is ! that. If you happen to want to override != as well, have at it.

It wasn't a good decision. Humans design languages, humans aren't perfect, C# isn't perfect. Shrug and Q.E.D.