c# - 为什么在实现 CompareTo 时必须重载运算符？

Question

假设我有一个实现 IComparable 的类型。

我原以为运算符 == 是合理的, != , > , < , >=和 <=会通过调用 CompareTo 自动“正常工作”，但如果我想使用它们，我必须覆盖它们。

从语言设计的角度来看，这样做有充分的理由吗？在任何情况下它对 A>B 真的有用吗？表现与 Compare(A,B)>0 不同？

Answer 1

整个情况令人烦恼。 C# 有太多表达相等和不相等的方式:

• == != > < >= <= 运算符(逻辑上是静态方法)
• Equals 静态方法(调用虚方法)、Equals 虚方法、ReferenceEquals 方法
• IComparable 和 IEquatable 接口(interface)

它们都有微妙的不同语义，除了静态等于之外，没有一个会自动使用另一个，也没有一个实际上具有我想要的行为。静态方法根据两个操作数的编译时类型进行分派(dispatch)；虚方法/接口(interface)方法根据操作数一个的运行时类型进行调度，这使得操作不对称；一侧的类型比另一侧的类型更重要。

我无法想象会有人认为我们现在的处境很好；如果没有任何限制，这不是进化的结果。但是托管语言的设计者确实有限制:CLR 不在接口(interface)契约或双虚拟分派(dispatch)中实现静态方法，或者在泛型类型参数上放置运算符约束的能力。因此，出现了多种解决方案来解决平等/不平等问题。

我认为，如果 CLR 和 C# 设计人员能够回到过去并告诉他们过去的自己 CLR v1 中应该包含哪些功能，那么接口(interface)中某种形式的静态方法将排在首位。如果接口(interface)中有静态方法，那么我们可以定义:

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>

然后您可以使用 <和 ==等等运算符来比较元素。