Ich versuche mein Bestes, um es klarer zu beschreiben. Worst Case, ich beschreibe es anders.
Die obere/untere Inferenz ist ein Teil eines phasengesteuerten Ansatzes zur Typinferenz in Bezug auf Typargumente, die für einen bestimmten generischen Methodenaufruf verwendet werden. Offensichtlich wird die obere/untere Inferenz nicht angewendet, wenn in der ersten Phase das Argument (E) explizit eingegeben wird. zB:
gegeben
public static T Choose<T>(T first, T second) {
return (rand.Next(2) == 0)? first: second;
}
ich Choose mit expliziten Typ Argumente aufrufen kann:
Choose<String>("first", "second");
Im Hinblick auf die Ober- oder Untergrenzen Folgerung, gibt es einige Auswirkungen im gesamten 7.5.2 die entscheiden, ob die untere oder obere Grenze der Inferenz überhaupt anwendbar ist. Zum Beispiel, 7.5.2.9 (und .10) Details, dass der Typ Parameter ist unfixiert für entweder oberen oder unteren Grenzen Inferenz auftreten. 7.5.2.5 Details, dass ein Typparameter nur dann unfixiert ist, wenn dieser Typparameter von einem anderen nicht fixierten Typparameter abhängt. Zum Beispiel
IEnumerable<TResult> Select<TSource, TResult>(IEnumerable<TSource> e,
Func<TSource, Result> f)
TResult „abhängig von“ TSource, weil die Art der TSource möglicherweise die Art der TResult bestimmen könnte. z.B. Bei einem Anruf wie Select(c, e->Name), TResult hängt der Typ Name in TSource.
In Bezug auf der ober und unteren Grenzen Inferenzen, für einen Parameter nicht fixierten Typs gegeben (X), dessen Typs (V) (siehe ersten Absatz), oder obere untere Grenzen des Typarguments nicht explizit deklariert (E) vom Typ U werden abgeleitet. Wenn der Typparameter kovariant ist (out Modifikator hat) und einer der Typen in der Untergrenze ein Kandidat für den Parameter ist, ist eine Untergrenze aufgetreten. Umgekehrt, wenn der Typparameter kontravariant ist (hat 'in' Modifikator) und einer der Typen in der Obergrenzenmenge ein Kandidat für den Parameter ist, dann ist eine Obergrenzen-Inferenz aufgetreten. z.B.mit Select(c, e->e.Name) und c war IEnumerable<Mammal> dann würde der Compiler ein unteren von Mammal gebunden schließen, weil die Typ-Parameter in IEnumerable covariant ist (zB ist es IEnumerable<out T> erklärt. Wenn es IEnumerable<in T> erklärt wurde dann eine obere Schranke geschlossen werden würde. Und wenn es erklärte Enumerabale<T> --with ohne in oder out dann wäre es invariant und weder Ober- noch Untergrenzen Folgerung gelten würde sein.)
klar, wenn Parametertyp muss weder covariant noch kontra sein kann dann genau ein Spiel auftreten
Ich denke nicht, dass Sie 7.5.2.9 isolieren können. Sie müssen die Gesamtheit von 7.5.2 übernehmen, um zu verstehen, was vor sich geht. –
@Damien_The_Unbeliever - Das ist ein bisschen was ich fürchte. Es fühlt sich an wie ein schlecht geschriebenes Programm. Ich muss die ganze Sache verstehen, nur um mit 1 Unterabschnitt umzugehen. Ich habe 7.5.2 durchgelesen ... aber es gibt so viel zu jonglieren in meinem Kopf Xi Xj, U, V, der angenommene Generic ..... –
7.5.2.9 definiert nicht wirklich, was eine unter-gebundene Schlussfolgerung * * ist **. Es ist eine Reihe von Anweisungen für das, was Sie tun sollen, wenn Sie (irgendwo in 7.5.2) eine Anweisung von z. "eine Untergrenze-Folgerung wird von U bis T gemacht". Und dann sagt Ihnen 7.5.2.11, ** wie ** diese Rückschlüsse verwendet werden. –