为什么构造函数不像泛型方法那样支持类型推断?
public class MyType<T> { private readonly T field; public MyType(T value) { field = value; } } var obj = new MyType(42); // why can't type inference work out that I want a MyType<int>?
尽管您可以通过工厂课程解决这个问题,
public class MyTypeFactory { public static MyType<T> Create<T>(T value) { return new MyType<T>(value); } } var myObj = MyTypeFactory.Create(42);
构造函数不能支持类型推断有实际或哲学上的原因吗?
构造器不能支持类型推断有什么哲学原因吗?
不用了
new Foo(bar)
那么我们就可以在范围内识别所有称为Foo的类型,而不管泛泛的通用性如何,然后使用经过修改的方法类型推断算法对每种类型进行重载解析。然后,我们必须创建一个“更好”算法,该算法确定 两种类型中名称相同但泛型类型不同 的两个适用的构造方法 中 哪个更好。为了保持向后兼容性,非泛型类型的ctor必须始终获胜。
构造函数不能支持类型推断有实际的原因吗?
是。即使该功能的好处胜过其成本(这是可观的),但仍不足以实现该功能。与我们可能要投资的所有其他可能功能相比,该功能不仅必须是净赢,而且还必须是一个 巨大的 净赢。它还必须比花时间和精力在错误修复,性能上更好。工作,以及其他我们可以投入的可能领域。理想情况下,它必须完全适合发行中的“主题”。
此外,正如您正确指出的那样,通过使用工厂模式,您可以获得此功能的好处,而实际上没有该功能本身。简单的解决方法的存在使功能实现的可能性降低。
此功能已经存在很长时间了。它从来没有足够高到无法实际实现的水平。
拟议的功能使其与列表的顶部足够接近,可以指定和设计C#6,但后来被剪切了。