为什么 C# 4.0 的协变/逆变仅限于参数化接口和委托类型？答案

【问题标题】：Why is C# 4.0's covariance/contravariance limited to parameterized interface and delegate types?为什么 C# 4.0 的协变/逆变仅限于参数化接口和委托类型？
【发布时间】：2011-03-25 06:27:57
【问题描述】：

这是 CLR 的限制还是与现有代码存在兼容性问题？

这是否与 C# 4.0 中委托组合的混乱变化有关？

编辑：是否有可能在 CLR 上运行一种使用协变/逆变而不受限制的语言？

【问题讨论】：

C# 委托变量是如何“搞砸”的？
@thecoop: stackoverflow.com/questions/2306814
请注意，Eric 的评论说委托 combining 在方差方面都搞砸了——不是一般的通用委托。
Why isn't there generic variance for classes in C# 4.0?的可能重复
Why does C# (4.0) not allow co- and contravariance in generic class types?的可能重复

标签： c# clr c#-4.0 covariance contravariance

【解决方案1】：

您将需要阅读 Eric Lippert 的帖子，了解它为何如此运作。缺点是它们允许尽可能多的差异，而不允许开发人员在编程中犯下可能导致难以追踪错误的严重错误。与 3.0 规则相比，4.0 中的差异量大大扩展，据我了解，这是在对开发人员有利和允许安全且不会因意外错误而造成太多麻烦之间的平衡。

http://blogs.msdn.com/b/ericlippert/archive/tags/covariance+and+contravariance/default.aspx

【讨论】：

虽然我能理解对可用性的担忧，但 Java 有这个问题已经很久了，几乎没有什么问题。我可以想象，与简化事情相比，这种限制会产生更复杂、更有问题的解决方法。
Java 和 .NET 泛型以完全不同的方式实现 - Java 是编译时，.NET 是运行时。并且添加特征（类差异）总是会产生更多的工作和更多的问题需要考虑。
@thecoop：您在回答中谈论的是开发人员的观点，而不是实施方面的技术困难。因此，如何在 JVM/CLR 上实现方差的实现细节并不是开发人员真正关心的问题。

【解决方案2】：

简单的回答：这是一个 CLR 限制。

（我在任何地方都没有看到一个好的、具体的解释......我不记得在 Eric 的博客系列中看到过关于它的内容，尽管我很可能在某个地方错过了它。 )

我要说的一件事是委托和接口都已经在真实类型之上形成了“间接层”；方法或类的视图，如果你愿意的话。从一种观点转变为另一种观点是相当合理的。对我来说，实际的课程感觉像是一种更具体的表示——从一种具体的表示转移到另一种感觉不太合理。这是一个非常敏感的解释，而不是真正的技术限制。

【讨论】：

这听起来很糟糕。所以基本上微软重复了 Sun 对泛型所做的错误？还是计划在未来的 CLR 更新中取消此限制？
实施不是一个“错误”——这是他们考虑的一个明确的设计决策，他们有理由按照他们的方式实施。
@soc：这没有像 Sun 在泛型方面的错误。他们是否会在未来的版本中允许它是任何人的猜测。
@thecoop：我不想争辩说他们没有比较所有技术可行的解决方案，而是选择了他们认为最好的解决方案。但这正是当人们问为什么他们没有正确使用泛型时 Sun 给我们的理由。我已经闻到这个决定将在几年后成为 PITA。
@Jon Skeet：很有趣。什么可以让 Oracle 考虑添加 JVM 支持，因为他们甚至在努力获得闭包/SAM/“防御者”方法/扩展方法/尾调用？

【解决方案3】：

这是一个 CLR 限制。更多评论请见Why does C# (4.0) not allow co- and contravariance in generic class types?。

【讨论】：