为什么IEquatable T在T＃4.0中没有逆变？

Question

IEquatable <T>可能已被声明为T中的逆变，因为它只在输入位置使用T（或者，等效地，U是T的子类型应该暗示IEquatable <T>是[IE]的一个子类型<U >）。

那么，为什么BCL团队没有使用'in'关键字对它进行注释（针对C＃4.0），就像他们使用许多其他通用接口（如完全类似的IComparable）一样？

Answer 1

我认为这主要是出于哲学原因而非技术限制 - 因为简单地注释界面是完全可能的。 IEquatable<T>旨在比较相同类型的对象以获得完全相等。 通常认为超类的实例等于子类的实例。 在这个意义上的平等也意味着类型平等。 这与IComparable<in T>略有不同。 在不同类型中定义相对排序顺序是明智的。

在IEquatable<T>上引用MSDN页面 ：

对实施者的说明：

将IEquatable<T>接口的type参数替换为实现此接口的类型 。

这句话进一步说明了IEquatable<T>旨在在单个具体类型的实例之间工作的事实。

Answer 2

可继承类型通常不应实现IEquatable<T> 。 如果IEquatable<T>包含一个GetHashCode()方法，则可以定义IEquatable<T>的语义， IEquatable<T>在检查为T时，项目应该比较相等。 不幸的是，这样的事实IEquatable<T>被绑定到相同的散列码作为Object.Equals意味着在一般IEquatable<T>具有基本上实现相同的语义Object.Equals 。

因此，如果IEquatable<BaseClass>实现除了在其中调用Object.Equals之外还执行任何操作，则重写Object.Equals和GetHashCode()并且不重新实现IEquatable<BaseClass>的派生类将最终导致实现中断那个界面; 简单地调用Object.Equals的IEquatable<BaseClass>的实现即使在那种情况下也能正常工作，但与没有实现IEquatable<T>的类相比，它没有真正的优势。

鉴于可继承类不应该首先实现IEquatable<T> ，协方差的概念与接口的正确实现无关。