[解決済み] なぜ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);

コンストラクタが型推論をサポートできないのは、実用的または哲学的な理由があるのでしょうか？

解決方法は？

コンストラクタが型推論をサポートできない哲学的な理由があるのでしょうか？

いいえ。

new Foo(bar)

の場合、総称のアリティに関係なく、スコープ内のFooと呼ばれるすべての型を識別し、修正したメソッド型推論アルゴリズムを用いてそれぞれについてオーバーロードの解決を行うことができます。次に、2つの適用可能なコンストラクタのうちどちらを選択するかを決定する「betterness」アルゴリズムを作成する必要があります。 同じ名前だが総称のアリティが異なる2つの型において がより良いコンストラクタです。後方互換性を維持するために、非属性型の ctor は常に勝たなければなりません。

コンストラクタが型推論をサポートできない現実的な理由があるのでしょうか？

はい。たとえその機能の利点がコストを上回るものであっても--それは相当なものですが--、それだけではその機能を実装するには十分ではありません。その機能が正味の利益になるだけでなく、その機能が 大きい 他のすべての可能な機能と比較しての勝利です。また、その時間と労力を、バグフィックスやパフォーマンス作業など、他の可能性のある分野に費やすよりも、優れていなければなりません。そして理想的には、そのリリースの「テーマ」にうまく適合するものでなければなりません。

さらに、あなたが正しく指摘しているように、ファクトリーパターンを使うことで、実際に機能そのものを持たずとも、この機能の利点を得ることができます。簡単な回避策が存在することで、その機能が実装される可能性は低くなります。

この機能は、ずっと前から可能性のある機能のリストに入っています。しかし、実際に実装されるにはまだ十分なレベルに達していません。

UPDATE 2015年3月

提案された機能は、C# 6の仕様と設計のためにトップに近づいたが、その後カットされた。