假设不需要向后兼容性，C#或.Net特性会被切断吗？

Question

任何产品或框架都会进化。主要是为了满足用户的需求，利用新的计算能力，使其变得更好。有时，主要的设计目标也会随着产品的变化而变化。C#或.net框架也不例外。正如我们所看到的，今天的第四版和第一版有很大的不同。但事情是这种进化的障碍--向后兼容。

在大多数框架/产品中，如果不需要支持向后兼容性，那么有些特性就会被切断。根据您的看法，C#/.net中的这些特性是什么？

请在每个答案中提到一个功能。

Answer 1

匿名方法。我认为每个人都同意，与我们在C# 3.0中添加的C#语法相比，为C# 2.0选择的匿名方法语法是笨重的。非常不幸的是，有两个几乎相同的语法来做同样的事情。

Answer 2

我会处理掉那些非通用的收藏品。它们是一个abomination...and --在很多情况下，我正在使用linq，并且不得不做一些类似的事情

var customObjects = container.CustomObjects.Cast<CustomObject>();

每次我这么做，我灵魂的一小部分就会死去。

Answer 3

作为一种类型的无效。为什么“空虚”是一种类型？它没有实例，没有值，不能使用它作为泛型类型参数、形式参数类型、本地类型、字段类型或属性类型。作为一种类型，它没有任何意义；相反，它是关于方法调用对虚拟机堆栈的影响的事实。但是虚拟机就是这样的:虚拟机。真正的机器会将返回的值放入寄存器(通常是x86上的EAX )，而根本不影响堆栈！形形色色的虚空只是个坏主意。

更糟的是:在指针类型中使用时，就像在void*中一样，它的含义与作为返回类型时的含义完全不同。现在它的意思是“指向未知类型的存储位置的指针”，这与它作为“不返回任何值的方法”的含义毫无关系。

我们可以将void*替换为指针类型为IntPtr。(以及void**和IntPtr*等等)我们可以用"Unit“替换void作为返回类型，这种类型只有一个值，即null。然后，CLR的实现可以决定单元类型函数调用可以适当地优化寄存器或堆栈的使用，同时知道可以安全地忽略正在“返回”的null。

在这种情况下，您不再需要单独的Func<A, R>和Action<T>委托。Action<T>就是Func<T, Unit>。