Also las ich Eric Lipperts "Constraints sind nicht Teil der Signatur" , und jetzt verstehe ich, dass die Spezifikation spezifiziert, dass Typ-Constraints NACH der Überladungsauflösung geprüft werden, aber ich bin mir immer noch nicht sicher, warum dies der Fall sein muss. Unten ist Eric's Beispiel:
%Vor% Dies wird nicht kompiliert, da die Überladungsauflösung für: Foo(new Giraffe()) besagt, dass Foo<Giraffe> die beste Überladungsübereinstimmung ist, aber dann die Typeinschränkungen fehlschlagen und ein Kompilierungsfehler ausgegeben wird. In Erics Worten:
Das Prinzip hier ist die Überladungsauflösung (und Methoden-Typ-Inferenz), um die bestmögliche Übereinstimmung zwischen einer Liste von Argumenten und der Liste formaler Parameter jeder Kandidatenmethode zu finden. Das heißt, sie betrachten die Signatur der Kandidatenmethode.
Typabhängigkeiten sind NICHT Teil der Signatur, aber Warum können sie nicht sein? In welchen Szenarien ist es eine schlechte Idee, Typenzwänge als Teil der Signatur zu betrachten? Ist es nur schwer oder gar nicht zu implementieren? Ich befürworte nicht, dass, wenn die bestausgewählte Überladung aus irgendeinem Grund unmöglich zu nennen ist, stillschweigend auf die zweitbeste überholt wird; Ich würde das hassen. Ich versuche nur zu verstehen, warum Typ-Constraints nicht verwendet werden können, um die Wahl der besten Überladung zu beeinflussen.
Ich stelle mir vor, dass intern im C # -Compiler nur für Überladungsauflösungszwecke (es schreibt die Methode nicht permanent neu) , das Folgende:
%Vor%wird umgewandelt in:
%Vor% Warum können Sie die Typabhängigkeiten nicht in die formale Parameterliste "hineinziehen"? Wie ändert sich die Signatur in irgendeiner Weise? Ich fühle, dass es nur die Unterschrift stärkt. Dann wird Foo<Reptile> niemals als Überlastungskandidat betrachtet.
Edit 2: Kein Wunder, dass meine Frage so verwirrend war. Ich habe Eric's Blog nicht richtig gelesen und habe das falsche Beispiel zitiert. Ich habe in dem Beispiel, das ich für passender halte, editiert. Ich habe auch den Titel geändert, um genauer zu sein. Diese Frage scheint nicht so einfach zu sein wie ich es mir vorgestellt habe, vielleicht fehlt mir ein wichtiges Konzept. Ich bin mir weniger sicher, dass dies Stackoverflow-Material ist, es könnte das Beste sein, wenn diese Frage / Diskussion an einen anderen Ort verschoben wird.
Der C # -Compiler muss Typabhängigkeiten nicht als Teil der Methodensignatur betrachten, da sie nicht Teil der Methodensignatur für die CLR sind. Es wäre katastrophal, wenn die Überladungsauflösung für verschiedene Sprachen anders funktioniert (hauptsächlich aufgrund der dynamischen Bindung, die zur Laufzeit auftreten kann und sich nicht von einer Sprache zur anderen unterscheiden sollte, sonst würden alle Höllen losbrechen).
Warum wurde entschieden, dass diese Einschränkungen nicht Teil der Methodensignatur für die CLR sein würden? Das ist eine andere Frage, und ich konnte nur schlecht informierte Vermutungen darüber machen. Ich werde die Leute wissen lassen, die Bescheid wissen.
Wenn T mehreren Einschränkungen entspricht, erstellen Sie eine Mehrdeutigkeit, die nicht automatisch aufgelöst werden kann. Zum Beispiel haben Sie eine generische Klasse mit der Einschränkung
where T : IFirst
und ein anderer mit der Einschränkung
where T : ISecond
Sie möchten nun, dass T eine Klasse ist, die sowohl IFirst als auch ISecond implementiert.
Konkreter Codebeispiel:
%Vor%Tags und Links c# generics overload-resolution nested-generics type-constraints