Gibt es eine Möglichkeit, die Typdefinitionen hier zu verallgemeinern? Idealerweise würde ich gerne den Typ von 'testInput' ändern und den Test zum Kompilierungszeitpunkt korrekt ableiten können.
%Vor%Aktualisierung: Ich kann den Typ der Funktion angeben, die an Compose übergeben wurde, aber dies gibt immer noch den Typ in der Zeile an.
%Vor%Ein kleiner Zusammenhang; Ich arbeite durch Wes Dyers Das Wunder der Monaden
Nun, da ich eine Rolle spiele, um heute Abend Text auszuspucken, werde ich meinen eigenen Stich machen. Ich sollte bemerken, dass ich kein Experte für den C # -Compiler bin, ich habe die Spezifikation (keine von ihnen ... für irgendetwas) gelesen, und obwohl dieser Artikel, den Sie verlinkt haben, wirklich interessant war, würde ich lügen, wenn ich es sagen würde Das war auch irgendeine Art von Experte (oder verstand alles zu 100%).
Vorbehalte beiseite, meine Meinung zu Ihrer Frage ist dies:
Gibt es irgendeinen Weg, den ich verallgemeinern kann? die Typdefinitionen hier?
Ich denke, die kurze Antwort ist nein. Mit den bereitgestellten Informationen gibt es einfach nicht genug Informationen für den Typinferenzteil des C # -Compilers, um genug Informationen aus der Verwendung der verschiedenen Variablen abzuleiten.
Wie die anderen Antworten hier zeigen, kann es vereinfacht werden. Sie können @ Lees IdentityFunc verwenden, um Typinferenz mit var identity zuzulassen. Aber auch mit diesem Zusatz ist es immer noch nicht möglich, mit Ihrem Beispielcode auf alle Typvariablen von Compose zu schließen.
Stellen Sie sich die folgende Situation vor:
%Vor%und
%Vor% Am Anfang könnte dies so aussehen, als ob test leicht auf int zurückgeführt werden könnte. Der Rückgabetyp von i.Compose kann jedoch nur aus der Verwendung abgeleitet werden. Der C # -Compiler wird dies offensichtlich nicht zulassen.
In diesem Beispiel müsste der Compiler bei Verwendung von c mit a rückwirkend den Rückgabetyp des Aufrufs von i.Compose<T, U, V>(n => n) auf Func<int, int> zurückführen. Dies ist im C # -Compiler offensichtlich nicht möglich. Nehmen Sie den Aufruf c(a) und der Compiler würde keine Kenntnis von der Verwendung von c haben, was jede Möglichkeit der Ableitung von T (nicht dass es sowieso möglich ist) entfernen würde. Es ist möglich, dass ein fortgeschritteneres Typ-Inferenzsystem diese Art von Schlussfolgerung basierend auf der Verwendung einer generischen Rückkehr (möglicherweise F # - ein anderes Thema, zu dem ich kein Experte bin) durchführen kann.
Da Wes Dyer dieses spezielle Beispiel nicht spezifisch verwendet, ist es unbekannt, ob es eine andere Magie gibt, die er verwendet, um den Grad der Typinferenz zu berücksichtigen, den Sie erreichen wollen.
Qualifizierte Leute wie Eric Lippert könnten Ihnen einen viel größeren Detaillierungsgrad bieten (und technische Genauigkeit / Schärfe). Ich habe eine große Antwort gelesen, die er hier auf eine Frage über Typinferenz geschrieben hat, aber ich kann sie nicht finden. Sein Blog enthält viele großartige Informationen. Sie könnten versuchen, ihn zu kontaktieren, wenn Sie interessiert sind. Auch seine Antwort auf diese Frage hier diskutiert Monaden (und verlinkt letztlich zurück zu Wes Dyer's Artikel) kaufen Sie könnten daran interessiert sein, es zu lesen: Monad in Plain Englisch? (Für den OOP-Programmierer ohne FP-Hintergrund)
Am ehesten kann ich den Parameter für n = & gt; n Lambda:
%Vor%Tags und Links c# type-inference