为什么C＃/ CLR不支持方法覆盖co / contra-variance？
关于C＃限制的黑客攻击有很多问题和答案，不允许在重写时将方法返回（和参数）类型更改为兼容类型，但为什么在C＃编译器或CLR中存在这种限制？ 正如我所看到的，如果允许共同/反向差异，没有什么可以破坏，那么背后的原因是什么呢？
可以要求扩展访问参数的类似问题 – 例如，使用公共方法覆盖受保护的内部方法（Java支持的内容，IIRC）
Eric Lippert已经比我更好地回答了这个问题。
看看他在C＃中关于协方差和逆变的系列
和
C＃4.0通用协方差和反差方法如何发挥作用？
编辑：埃里克指出，他没有谈论返回类型的方差，但我决定保留这个答案的链接，因为它是一个很酷的系列文章，如果查找这个主题，有人可能会觉得它很有用。
这个function已被要求 ，差不多5年前，微软已经回复了“感谢你记录这个。我们听到了很多这样的要求。我们会在下一个版本中考虑它。”
现在我引用Jon Skeet，因为如果没有Jon Skeet的答案，它就不会是StackOverflow的正确答案。 协方差和void返回类型
我强烈怀疑答案在于CLR的实现，而不是任何深层次的语义原因 – CLR可能需要知道是否会有返回值，以便对堆栈做适当的事情。 即便如此，在优雅方面似乎有点可惜。 我不能说我曾经在现实生活中感受到这一点，并且只需将
Func的转换器写入Action在.NET 3.5中伪造（最多四个参数）就相当容易了Action，Func来Action等等虽然有点摇晃:)
这个答案不是在谈论C＃，而是帮助我更好地理解这些问题，也许它会帮助其他人： 为什么没有参数反差来覆盖？
引入返回值协方差的接缝没有基本的缺点，因为Java和C ++已经使用过。 然而，通过引入forms参数的逆变量，存在真正的混淆。 我认为这个答案https://stackoverflow.com/a/3010614/1443505在C ++中也适用于C＃。
确实如此，你只需要等待VS2010 / .Net 4.0。
为了扩展Joel的答案 – CLR长期以来支持有限的方差，但是C＃编译器直到4.0才使用它们，在通用接口和委托上使用新的“in”和“out”修饰符。 原因很复杂，我会试图解释，但它并不像看起来那么简单。
将“受保护的内部”方法重新制作为“公共”方法; 你可以用方法隐藏来做到这一点：
public new void Foo(...) { base.Foo(...); }
（只要论点等都是公开的） – 任何用途？