Warum unterstützt C# keine impliziten generischen Typen für Klassenkonstruktoren?

Question

C# benötigen Sie keine generischen Typparameter angeben, ob der Compiler es zum Beispiel entnehmen kann,:

List<int> myInts = new List<int> {0,1,1, 
    2,3,5,8,13,21,34,55,89,144,233,377, 
    610,987,1597,2584,4181,6765}; 

//this statement is clunky 
List<string> myStrings = myInts. 
    Select<int,string>(i => i.ToString()). 
    ToList<string>(); 

//the type is inferred from the lambda expression 
//the compiler knows that it's taking an int and 
//returning a string 
List<string> myStrings = myInts. 
    Select(i => i.ToString()). 
    ToList(); 

Diese für anonyme Typen benötigt wird, wo man nicht weiß, was der Typ-Parameter sein würde (In Intellisense erscheint es als 'a), weil es vom Compiler hinzugefügt wird.

Class-Level-Typ Parameter lassen Sie sich nicht Sie dies tun:

//sample generic class 
public class GenericDemo<T> 
{ 
    public GenericDemo (T value) 
    { 
     GenericTypedProperty = value; 
    } 

    public T GenericTypedProperty {get; set;} 
} 

//why can't I do: 
int anIntValue = 4181; 
var item = new GenericDemo(anIntValue); //type inference fails 

//however I can create a wrapper like this: 
public static GenericDemo<T> Create<T> (T value) 
{ 
    return new GenericDemo<T> (value); 
} 

//then this works - type inference on the method compiles 
var item = Create(anIntValue); 

Warum nicht C# Unterstützung dieser Klasse Ebene generic Typinferenz?

Answer 1

Eigentlich ist Ihre Frage nicht schlecht. Ich habe in den letzten paar Jahren mit einer generischen Programmiersprache gespielt und obwohl ich nie dazu gekommen bin, sie wirklich zu entwickeln (und wahrscheinlich auch nie), habe ich viel über generische Typinferenz nachgedacht und eine meiner wichtigsten Prioritäten war immer die Konstruktion von Klassen zu erlauben, ohne den generischen Typ angeben zu müssen.

C# fehlt einfach das Regelwerk, um dies zu ermöglichen. Ich denke, die Entwickler haben nie die Notwendigkeit gesehen, dies zu berücksichtigen. Eigentlich würde der folgende Code Ihrem Vorschlag sehr nahe kommen und das Problem lösen. Alle C# benötigt ist eine zusätzliche Syntax-Unterstützung.

class Foo<T> { 
    public Foo(T x) { … } 
} 

// Notice: non-generic class overload. Possible in C#! 
class Foo { 
    public static Foo<T> ctor<T>(T x) { return new Foo<T>(x); } 
} 

var x = Foo.ctor(42); 

Da dieser Code tatsächlich funktioniert, haben wir gezeigt, dass das Problem nicht ein von Semantik ist aber nur eine der Unterstützung fehlt. Ich denke, ich muss meinen vorherigen Beitrag zurücknehmen. ;-)

Answer 2

Warum unterstützt C# diese generische Typ-Inferenz auf Klassenebene nicht?

Weil sie im Allgemeinen mehrdeutig sind. Im Gegensatz dazu ist Typinferenz für Funktionsaufrufe trivial (wenn alle Typen in Argumenten vorkommen). Aber im Fall von Konstruktoraufrufen (verherrlichte Funktionen, um der Diskussion willen) muss der Compiler mehrere Ebenen gleichzeitig auflösen. Eine Ebene ist die Klassenebene und die andere ist die Konstruktorargumentebene. Ich glaube, das zu lösen ist algorithmisch nicht-trivial. Intuitiv würde ich sagen, dass es sogar NP-vollständig ist.

Um einen Extremfall dar, in der Auflösung nicht möglich ist, stellen Sie sich die folgende Klasse und mir sagen, was der Compiler tun soll:

class Foo<T> { 
    public Foo<U>(U x) { } 
} 

var x = new Foo(1); 

Answer 3

Dank Konrad, das ist eine gute Antwort (1), aber nur zu erweitern darauf.

Nehmen wir an, dass C# eine explizite Konstruktorfunktion hat:

//your example 
var x = new Foo(1); 

//becomes 
var x = Foo.ctor(1); 

//your problem is valid because this would be 
var x = Foo<T>.ctor<int>(1); 
//and T can't be inferred 

Sie haben ganz recht, dass der erste Konstruktor kann nicht geschlossen werden.

Lassen Sie sich nun auf die Klasse zurück

class Foo<T> 
{ 
    //<T> can't mean anything else in this context 
    public Foo(T x) { } 
} 

//this would now throw an exception unless the 
//typeparam matches the parameter 
var x = Foo<int>.ctor(1); 

//so why wouldn't this work? 
var x = Foo.ctor(1); 

Natürlich, wenn ich Ihren Konstruktor zurück in (mit seinem alternativen Typ) füge wir einen zweideutigen Ruf haben - genau so, wie wenn eine normale Überlast-Methode konnte nicht gelöst werden.