为什么C＃构造函数不能推断类型？

Question

为什么C＃构造函数不能推断类型？

为什么构造函数不支持类型推断，就像通用方法一样？

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);

构造函数不支持类型推断是否存在实际或哲学原因？

Answer 1

有没有一个哲学上的原因，为什么构造函数不能支持类型推断？不，当你有new Foo(bar)然后我们可以在范围内识别所有称为Foo的类型，而不管通用arity，然后使用修改的方法类型推断算法对每个类型执行重载解析。然后，我们必须创建一个“更好”算法，该算法确定两个类型中具有相同名称但不同通用arity的两个适用构造函数中哪一个是更好的构造函数。为了保持向后兼容性，非泛型类型的ctor必须始终获胜。是否有一个实际的原因，为什么构造函数不能支持类型推断？是。即使该功能的好处超过其成本 - 这是相当大的 - 但这还不足以实现功能。这个功能不仅必须是一个净赢，它必须是一个巨大的净胜利，相比我们可能投资的所有其他可能的功能。它还必须比花费时间和精力修复bug，性能更好工作，以及我们可以付出努力的其他可能领域。理想情况下，它必须适合发布的“主题”。此外，正如您正确指出的那样，通过使用工厂模式，您可以获得此功能的好处，而无需实际拥有该功能。易于使用的变通方法使得功能实现的可能性降低。此功能已在很长一段时间内列在可能的功能列表中。它实际上从未在列表中足够高的地方实现。

Answer 2

public&nbsp;class&nbsp;MyType<T>&nbsp;{&nbsp; &nbsp;&nbsp;&nbsp;private&nbsp;readonly&nbsp;T&nbsp;field;&nbsp; &nbsp;&nbsp;&nbsp;public&nbsp;MyType(T&nbsp;value)&nbsp;{&nbsp;field&nbsp;=&nbsp;value;&nbsp;}&nbsp;}他们可以，没有必要再次告诉构造函数“T是什么”，因为你已经在课堂上已经完成了这一点。还您的工厂是不正确，你需要有public class MyTypeFactory<T>不只是public class MyTypeFactory-除非你声明里面的工厂MyType类编辑更新：那么，42是长，短，是int还是其他什么？假设您有以下内容class&nbsp;Base{ &nbsp;&nbsp;&nbsp;public&nbsp;virtual&nbsp;void&nbsp;DoStuff()&nbsp;{&nbsp;Console.WriteLine("Base");&nbsp;}}class&nbsp;Foo&nbsp;:&nbsp;Base{ &nbsp;&nbsp;&nbsp;public&nbsp;override&nbsp;void&nbsp;DoStuff()&nbsp;{&nbsp;Console.WriteLine("Foo");&nbsp;&nbsp;}}然后你做到了这一点var&nbsp;c&nbsp;=&nbsp;new&nbsp;Foo();var&nbsp;myType&nbsp;=&nbsp;new&nbsp;MyType(c);你期望foo被使用，还是base？我们需要告诉编译器代替使用什么T当你真的想要打字&nbsp;base因此var&nbsp;myType&nbsp;=&nbsp;new&nbsp;MyType<Base>(c);

Answer 3

泛型类型推断不能像你希望的那样对构造函数起作用的主要原因是因为当你声明的所有类都是“MyType <T>”时，类“MyType”甚至不存在。请记住，同时拥有两者是合法的：public&nbsp;class&nbsp;MyType<T>&nbsp;{}和public&nbsp;class&nbsp;MyType&nbsp;{}两者都是合法的。如果您确实声明了两者，并且它们都声明了冲突的构造函数，那么您将如何消除语法歧义？