为什么C#不对泛型进行“简单”类型推断？

Question

只是好奇:当然，我们都知道泛型类型推断的一般情况是无法确定的。因此C#根本不会做任何类型的子类型:如果Foo是泛型的，那么Foo就不是Foo或Foo的一个子类型，或者您可能会编造的任何其他类型的子类型。当然，我们都用丑陋的接口或抽象的类定义来解决这个问题。

但是..。如果你不能克服一般的问题，为什么不把解决办法限制在简单的情况下。例如，在我上面的列表中，很明显，Foo是Foo的一个子类型，检查起来非常简单。对Foo的检查也是一样。

那么，如果他们说，“哎哟，我们会尽我们所能”的话，还有其他深层次的恐惧会从深渊里溜出来吗？或者，这仅仅是微软语言专家的宗教纯洁吗？

更新：

这是一条很老的线。最近，C#有var，它解决了我抱怨的一半，然后使用匿名委托的Linq风格，它有一个很好的符号，不需要输入相同的东西两次。因此，我所反对的每一个方面都通过最近对C#的更改而得到了解决(也许我只是花了一段时间来了解当我发布这个帖子时所介绍的事情.)我现在在Isis2系统中使用这些新特性，用于可靠的云计算(isis2.codeplex.com)，因此，我认为库的外观和感觉都非常干净。看看，让我知道你的想法)。- Ken Birman (2014年7月)

Answer 1

他们已经解决了许多“容易”的情况: C# 4.0支持接口和委托中的通用类型参数的协方差与反方差。但不幸的是没有上课。

解决这个限制是相当容易的：

List<Foo> foos = bars.Select(bar => (Foo)bar).ToList();

Answer 2

显然，Foo<int>是Foo<T>的一个子类型。

也许是对你，但不是对我。

对我来说，这种类型系统的巨大漏洞是完全不能接受的。如果你想像那样把类型安全抛出窗外，我宁愿使用一种动态类型的语言，它实际上是为这种东西而设计的。

数组是协变的，即使已知这会破坏类型安全，这已经够糟糕的了，现在您想要对所有的事情都破坏它。

这就是一个类型系统的核心所在。类型系统所做的就是拒绝程序。由于Rice的定理，那些被拒绝的程序包括类型完整、类型安全的程序.

这是一个巨大的代价。放弃表现力，阻止我写有用的程序。为了证明这一成本的合理性，类型系统最好还大的时间。它基本上有两种方法:在程序级和类型安全级别上返回类型级别的表现力。

前者已经过时，仅仅是因为C#的类型系统功能不够强大，我无法表达任何有趣的东西。这只剩下后者，而且由于null、协变数组、无限制的副作用、unsafe等因素，它的基础已经相当不稳定了。通过使通用类型自动协变，你或多或少会完全去除剩下的最后一部分类型--安全。

只有极少数情况下S <: T ⇒ G<S> <: G<T>实际上是类型安全的。(IEnumerable就是这样的例子。)而且，在同样多的情况下，只有S <: T ⇒ G<T> <: G<S>是类型安全的。(IObservable，IComparer，IComparable，IEqualityComparer.)通常，G<S> <: G<T>和G<T> <: G<S>都不是类型安全的.

Answer 3

关键是你不可能在所有的情况下都这样做，所以你也不会去做任何事情。你在哪里划的线是问题所在。如果您没有比所有使用C#的人都知道它不会这样做的话。如果你有一段时间去做，那就是它变得复杂了。它可以成为一个猜测游戏，你的代码将如何运行。对于程序员来说，容易的和不容易的事情都会变得复杂，并可能导致代码中的错误。

这是一种绝对会造成大破坏的情况。假设您可以推断场景A中的boo是bar，则会有其他人来更改基本类型的一部分，这不再适用。让它要么总是适用，要么永远不适用，你永远不会遇到这种情况。在一个复杂的环境中，跟踪这样的问题可能是一场噩梦，特别是当您在编译期间(反射、DLR等)考虑到这一点时。在前面编写手动处理转换的代码要比假设它在您的场景中工作要容易得多，因为在某些情况下，它可能不会(不包括升级到新版本)。

C# 4.0确实修复了其中的一些问题，因为它们允许对程序员来说是“安全的”。