为什么 C# 构造函数不能推断类型? [英] Why can't the C# constructor infer type?

问题描述

为什么构造函数不支持泛型方法的类型推断?

Why is type inference not supported for constructors the way it is for generic methods?

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>?

虽然你可以通过工厂类来解决这个问题，

Though you could get around this with a factory class,

public class MyTypeFactory
{
   public static MyType<T> Create<T>(T value)
   {
      return new MyType<T>(value);
   }
}
var myObj = MyTypeFactory.Create(42);

构造函数不支持类型推断是否有实际或哲学上的原因?

Is there a practical or philosophical reason why the constructor can't support type inference?

推荐答案

构造函数不支持类型推断是否有哲学上的原因?

Is there a philosophical reason why the constructor can't support type inference?

没有.当你有

new Foo(bar)

然后我们可以在范围内识别所有称为 Foo 的类型，而不考虑泛型，然后使用修改后的方法类型推断算法对每个类型进行重载解析.然后，我们必须创建一个更好"算法，以确定具有相同名称但泛型不同的两种类型中的两个适用构造函数中的哪一个是更好的构造函数.为了保持向后兼容性，非泛型类型的 ctor 必须始终获胜.

then we could identify all types called Foo in scope regardless of generic arity, and then do overload resolution on each using a modified method type inference algorithm. We'd then have to create a 'betterness' algorithm that determines which of two applicable constructors in two types that have the same name but different generic arity is the better constructor. In order to maintain backwards compatibility a ctor on a non-generic type must always win.

构造函数不支持类型推断是否有实际原因?

Is there a practical reason why the constructor can't support type inference?

是的.即使该功能的好处超过其成本——这是相当可观的——也不足以实现一个功能.与我们可能投资的所有其他可能的功能相比，该功能不仅必须是净赢，还必须是巨大净赢.它还必须比花时间更好并在错误修复、性能工作以及我们可以投入的其他可能领域上的努力.理想情况下，它必须与发布的主题"完美契合.

Yes. Even if the benefit of the feature outweighs its costs -- which are considerable -- that's not sufficient to have a feature implemented. Not only does the feature have to be a net win, it has to be a large net win compared to all the other possible features we could be investing in. It also has to be better than spending that time and effort on bug fixing, performance work, and other possible areas that we could put that effort. And ideally it has to fit in well to whatever the "theme" is of the release.

此外，正如您正确指出的那样，通过使用工厂模式，您可以在不实际拥有该功能的情况下获得该功能的好处.简单的变通方法的存在降低了实现某个功能的可能性.

Furthermore, as you correctly note, you can get the benefits of this feature without actually having the feature itself, by using a factory pattern. The existence of easy workarounds makes it less likely that a feature will ever be implemented.

此功能已在可能的功能列表中很久了.它在列表中从来没有足够高到可以实际实施.

This feature has been on the list of possible features for a long time now. It's never been anywhere near high enough on the list to actually get implemented.

提议的功能使它足够接近要指定和设计的 C# 6 列表的顶部，但随后被删除.

The proposed feature made it close enough to the top of the list for C# 6 to be specified and designed, but was then cut.

这篇关于为什么 C# 构造函数不能推断类型?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！