Почему мне приходится перегружать операторы при реализации CompareTo?

Вся ситуация неприятная. В C# слишком много способов выразить равенство и неравенство:

• операторы == != > ‹ >= ‹= (которые являются логически статическими методами)
• статический метод Equals (который вызывает виртуальный метод), виртуальный метод Equals, метод ReferenceEquals
• Интерфейсы IComparable и IEquatable

Все они имеют немного разную семантику, и, за исключением статического Equals, ни один из них не использует автоматически другой, и ни один из них на самом деле не имеет нужного мне поведения. Статические методы отправляются на основе типа времени компиляции обоих операндов; виртуальные методы/методы интерфейса отправляются на основе типа времени выполнения одного из операндов, что делает операцию асимметричной; тип одной стороны имеет большее значение, чем тип другой.

Я не могу себе представить, чтобы кто-то думал, что положение, в котором мы находимся, прекрасно; при отсутствии ограничений это не то, что могло бы развиться. Но у разработчиков управляемых языков есть ограничения: CLR не реализует статические методы в контрактах интерфейса или двойную виртуальную диспетчеризацию, или возможность наложить ограничение оператора на параметр универсального типа. И поэтому появилось множество решений для решения проблемы равенства/неравенства.

Я думаю, что если бы разработчики CLR и C# вернулись в прошлое и рассказали себе в прошлом, какие функции должны быть в версии 1 CLR, некоторые формы статических методов в интерфейсах были бы первыми в списке. Если бы в интерфейсе были статические методы, то мы могли бы определить:

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

И тогда, если у вас есть:

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

Затем вы можете использовать операторы < и == и так далее для сравнения элементов.

Две основные причины:

1. Это общая структура для всех операторов. Хотя операторы сравнения могут никогда не иметь альтернативной семантики, очень полезна структура, допускающая очень различную семантику для некоторых других операторов. Реализация отдельной структуры только для операторов сравнения потребовала бы отказа от некоторых других, возможно, гораздо более полезных функций. Взгляните на эту элегантную реализацию BNF в C# в качестве примера.
2. Реализации по умолчанию для типов значений, которые имеют его, по необходимости полагаются на отражение и, следовательно, ужасно неэффективны. Только вы действительно знаете наиболее эффективный способ реализации этих операторов для ваших классов. Во многих случаях не все поля структуры нужно сравнивать для проверки на равенство, и не всегда нужно объединять все поля в подходящей реализации GetHashCode. Никакая реализация по умолчанию не может определить это для всех типов, потому что это сводится к проблеме остановки.

Обновление в соответствии с Eric Lippert среди прочего, ниже приведена подходящая стандартная реализация операторов сравнения в C# для 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);
}

Просто добавьте пользовательское определение для private static int CompareTo(UDT x, UDT y) и перемешайте.