Why do I have to overload operators when implementing CompareTo?

Question

Let\'s say I have a type that implements IComparable.

I would have thought it\'s reasonable to expect that the operators ==, !=, >

Answer 1

Two main reasons:

1. It is a general structure for all operators. While the comparison operators may never have alternative semantics, there is great utility in a structure that allows very different semantics for some of the other operators. Implementing a separate structure for just the comparison operators would have required omitting some other, probably much more useful, feature. Check out this elegant implementation of BNF within C# for an example.
2. The default implementations, for the case of value types that have it, relies of necessity on Reflection, and thus is horribly inefficient. Only you actually know the most efficient way to implement these operators for your classes. In many cases not all fields of a struct need to be compared to test equality, nor do all fields always need to be combined in a suitable GetHashCode implementation. No default implementation can ever determine that for all types, because it is reducible to the Halting Problem.

Update as per Eric Lippert among others, the following is the appropriate standard implementation of the comparison operators in C# for a type UDT:

public int  CompareTo(UDT x) { return CompareTo(this, x); }
public bool Equals(UDT x)    { return CompareTo(this, x) == 0; }
public static bool operator  < (UDT x, UDT y) { return CompareTo(x, y)  < 0; }
public static bool operator  > (UDT x, UDT y) { return CompareTo(x, y)  > 0; }
public static bool operator <= (UDT x, UDT y) { return CompareTo(x, y) <= 0; }
public static bool operator >= (UDT x, UDT y) { return CompareTo(x, y) >= 0; }
public static bool operator == (UDT x, UDT y) { return CompareTo(x, y) == 0; }
public static bool operator != (UDT x, UDT y) { return CompareTo(x, y) != 0; }
public override bool Equals(object obj)
{
    return (obj is UDT) && (CompareTo(this, (UDT)obj) == 0);
}

Just add the custom definition for private static int CompareTo(UDT x, UDT y) and stir.

Answer 2

The whole situation is vexing. C# has too many ways to express equality and inequality:

• the == != > < >= <= operators (which are logically static methods)
• the Equals static method (which calls the virtual method), the Equals virtual method, the ReferenceEquals method
• The IComparable and IEquatable interfaces

They all have subtly different semantics and with the exception of static Equals, none automatically uses the other, and none actually has the behavior that I want. Static methods are dispatched based on the compile-time type of both operands; the virtual methods / interface methods are dispatched based on the run-time type of one of the operands, which makes the operation asymmetric; the type of one side matters more than the type of the other.

I can't imagine that anyone thinks that the situation we're in is great; given no constraints, this is not what would have evolved. But managed language designers do have constraints: the CLR does not implement static methods in interface contracts or double-virtual dispatch, or the ability to put an operator constraint on a generic type parameter. And therefore multiple solutions have evolved to solve the equality/inequality problem.

I think that were the CLR and C# designers to go back in time and tell their past selves what features ought to be in v1 of the CLR, some form of static methods in interfaces would be high on the list. If there were static methods in interface then we can define:

interface IComparable<in T, in U> 
{
    static bool operator <(T t, U u);
    static bool operator >(T t, U u);
    ... etc

And then if you have:

static void Sort<T>(T[] array) where T : IComparable<T, T>

You could then use the < and == and so on operators to compare elements.