为什么 IEnumerable在 C# 4 中进行协变？

Question

在 C# 的早期版本中，IEnumerable 的定义如下：

public interface IEnumerable<T> : IEnumerable

从 C# 4 开始，定义是：

public interface IEnumerable<out T> : IEnumerable

• 它只是为了让 LINQ 表达式中烦人的强制转换消失吗？
• 这不会引入与 C# 中的 string[] <: object[] （损坏的数组方差）相同的问题吗？
• 从兼容性的角度来看，协方差的添加是如何完成的？早期代码是否仍可在更高版本的 .NET 上运行，或者是否需要重新编译？反过来呢？
• 以前使用此接口的代码在所有情况下都严格不变吗？或者某些用例现在的行为是否可能有所不同？

Answer 1

为了：

这只是为了让 LINQ 表达式中烦人的强制转换消失吗？

它使事物的行为像人们通常期望的那样;p

这不会引入与 C# 中的 string[] <: object[] （损坏的数组方差）相同的问题吗？

不;因为它不公开任何 Add 机制或类似机制（并且不能；out 和 in 在编译器中强制执行）

从兼容性的角度来看，协方差的添加是如何完成的？

CLI 已经支持它，这只会让 C#（以及一些现有的 BCL 方法）意识到它

早期代码是否仍可在更高版本的 .NET 上运行，或者是否需要重新编译？

然而，它完全向后兼容：依赖 C# 4.0 变体的 C# 无法在 C# 2.0 等编译器中编译

反过来呢？

这并非没有道理

以前使用此接口的代码在所有情况下都严格不变吗？或者某些用例现在的行为是否可能有所不同？

某些 BCL 调用 (IsAssignableFrom) 可能返回不同的结果现在

Answer 2

这只是为了让 LINQ 表达式中烦人的强制转换消失吗？

不仅在使用 LINQ 时。只要有 IEnumerable 并且代码需要 IEnumerable，它就很有用。

这不会引入与 C# 中的 string[] <: object[] （损坏的数组方差）相同的问题吗？

不可以，因为只有返回该类型值但不接受它们的接口才允许协变。所以很安全。

从兼容性的角度来看，协方差的添加是如何完成的？早期代码是否仍可在更高版本的 .NET 上运行，或者是否需要重新编译？反过来呢？

我认为已经编译的代码大部分都会按原样工作。某些运行时类型检查（is、IsAssignableFrom...）将在之前返回 false 的地方返回 true。

以前使用此接口的代码在所有情况下都严格不变吗？或者某些用例现在的行为是否可能有所不同？

不确定你的意思

---

最大的问题与重载解析有关。由于现在可以进行额外的隐式转换，因此可以选择不同的重载。

void DoSomething(IEnumerabe<Base> bla);
void DoSomething(object blub);

IEnumerable<Derived> values = ...;
DoSomething(values);

但当然，如果这些重载的行为不同，那么 API 就已经设计得很糟糕了。

Answer 3

Marc 和 CodeInChaos 的答案非常好，但只是添加一些更多细节：

首先，听起来您有兴趣了解我们为实现此功能而经历的设计过程。如果是这样，那么我鼓励您阅读我在设计和实现该功能时撰写的一系列长篇文章。从页面底部开始：

协变和逆变博客文章

这只是为了让 LINQ 表达式中烦人的强制转换消失吗？

不，这不仅仅是为了避免 Cast 表达式，而是这样做是鼓励我们实现此功能的动机之一。我们意识到，“为什么我不能在这种采用动物序列的方法中使用长颈鹿序列？”的数量将会增加。问题，因为 LINQ 鼓励使用序列类型。我们知道我们首先要向 IEnumerable 添加协方差。

我们实际上考虑过在 C# 3 中使 IEnumerable 协变，但认为如果不引入整个功能供任何人使用，这样做会很奇怪。

这不会引入与 C# 中的 string[] <: object[] （损坏的数组方差）相同的问题吗？

它不会直接引入该问题，因为编译器仅在已知类型安全时才允许变化。然而，它确实保留了损坏的数组方差问题。通过协方差，IEnumerable 可以隐式转换为 IEnumerable，因此如果您有一个字符串数组序列，则可以将其视为作为对象数组的序列，然后您会遇到与以前相同的问题：您可以尝试将长颈鹿放入该字符串数组中并在运行时得到异常。

从兼容性的角度来看，协方差的添加是如何完成的？

小心。

早期代码是否仍可在更高版本的 .NET 上运行，或者是否需要重新编译？

只有一种方法可以找出答案。尝试一下，看看会失败！

如果 X != Y，无论类型系统如何更改，尝试强制针对 .NET X 编译的代码针对 .NET Y 运行通常是一个坏主意。

反过来呢？

同样的答案。

某些用例现在的行为是否可能会有所不同？

绝对地。在以前不变的地方使接口协变在技术上是一个“重大改变”，因为它可能会导致工作代码中断。例如：

if (x is IEnumerable<Animal>)
    ABC();
else if (x is IEnumerable<Turtle>)
    DEF();

当 IE 不是协变时，此代码选择 ABC 或 DEF 或两者都不选择。当它是协变时，它不再选择 DEF。

或者：

class B     { public void M(IEnumerable<Turtle> turtles){} }
class D : B { public void M(IEnumerable<Animal> animals){} }

之前，如果您以海龟序列作为参数对 D 的实例调用 M，重载决策会选择 BM，因为这是唯一适用的方法。如果 IE 是协变的，则重载决策现在选择 DM，因为两种方法都适用，并且派生程度较高的类上的适用方法始终优于派生程度较低的类上的适用方法，无论参数类型匹配是否精确。

或者：

class Weird : IEnumerable<Turtle>, IEnumerable<Banana> { ... }
class B 
{ 
    public void M(IEnumerable<Banana> bananas) {}
}
class D : B
{
    public void M(IEnumerable<Animal> animals) {}
    public void M(IEnumerable<Fruit> fruits) {}
}

如果 IE 是不变的，那么对 dM(weird) 的调用解析为 BM 如果 IE 突然变得协变，那么 DM 的两种方法都适用，两者都比基类上的方法更好，而且都不是比另一个更好，因此，重载解析变得不明确，我们报告错误。

当我们决定进行这些重大更改时，我们希望（1）这种情况很少见，并且（2）当出现这种情况时，几乎总是因为该类的作者正在尝试模拟语言中的协方差那个没有。通过直接添加协方差，希望当代码在重新编译时“中断”时，作者可以简单地删除试图模拟现有功能的疯狂装备。