Freigeben über

Methodengruppenverbesserungen für natürliche Typen

  • Artikel

Anmerkung

Dieser Artikel ist eine Featurespezifikation. Die Spezifikation dient als Designdokument für das Feature. Es enthält vorgeschlagene Spezifikationsänderungen sowie Informationen, die während des Entwurfs und der Entwicklung des Features erforderlich sind. Diese Artikel werden veröffentlicht, bis die vorgeschlagenen Spezifikationsänderungen abgeschlossen und in die aktuelle ECMA-Spezifikation aufgenommen werden.

Es kann einige Abweichungen zwischen der Featurespezifikation und der abgeschlossenen Implementierung geben. Diese Unterschiede werden in den entsprechenden Hinweisen zum Language Design Meeting (LDM) erfasst.

Weitere Informationen zum Einführen von Featurespezifikationen in den C#-Sprachstandard finden Sie im Artikel zu den Spezifikationen.

Champion Issue: https://github.com/dotnet/csharplang/issues/7429

Zusammenfassung

Dieser Vorschlag optimiert die Bestimmung der natürlichen Art einer Methodengruppe auf verschiedene Arten:

  1. Betrachten Sie die Kandidaten für jeden Bereich (zuerst Instanz-Methoden, dann jeder Bereich und anschließend der Bereich der Erweiterungsmethoden)
  2. Sortiere Kandidaten aus, die keine Chance haben, Erfolg zu haben, damit sie die Ermittlung einer eindeutigen Signatur nicht beeinträchtigen.
    • Bereinigen Sie generische Instanzmethoden, wenn keine Typargumente angegeben sind (var x = M;).
    • Beschneiden generischer Erweiterungsmethoden auf der Grundlage der Möglichkeit, die Erweiterung zu reduzieren, und auf der Grundlage von Beschränkungen

Kontext zum natürlichen Typ der Methodengruppe

In C# 10 erhielten Methodengruppen einen schwachen natürlichen Typ.
Dieser Typ ist ein "schwacher Typ", da er nur ins Spiel kommt, wenn die Methodengruppe nicht zieltypiert ist (d. h. es spielt keine Rolle in System.Action a = MethodGroup;).
Dieser schwache natürliche Typ ermöglicht Szenarien wie var x = MethodGroup;.

Zur Referenz: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-10.0/lambda-improvements.md#natural-function-type

Eine Methodengruppe hat einen natürlichen Typ, wenn alle Kandidatenmethoden in der Methodengruppe eine gemeinsame Signatur haben. (Wenn die Methodengruppe Erweiterungsmethoden enthalten kann, gehören zu den Kandidaten auch der enthaltende Typ und alle Bereiche der Erweiterungsmethoden.)

In der Praxis bedeutet dies, dass wir:

  1. Konstruieren Sie das Set aller Kandidatenmethoden:
  • Methoden für den relevanten Typ befinden sich im Satz, wenn sie statisch sind und der Empfänger ein Typ ist oder wenn sie nicht statisch sind und der Empfänger ein Wert ist.
  • Erweiterungsmethoden (über alle Bereiche hinweg), die reduziert werden können, sind in dem Set festgelegt
  1. Wenn die Signaturen aller Kandidaten nicht übereinstimmen, hat die Methodengruppe keinen natürlichen Typ.
  2. Wenn die Arität der resultierenden Signatur nicht mit der Anzahl der angegebenen Typargumente übereinstimmt, weist die Methodengruppe keinen natürlichen Typ auf.
  3. Andernfalls wird die resultierende Signatur als natürlicher Typ verwendet.

Vorschlag

Das Prinzip besteht darin, Bereich für Bereich vorzugehen und Kandidaten, von denen wir wissen, dass sie nicht erfolgreich sein können, so früh wie möglich auszusortieren (dasselbe Prinzip wird bei der Überladungsauflösung verwendet).

  1. Für jeden Bereich legen wir das Set aller Kandidatenmethoden fest:
  • für den anfänglichen Bereich sind Methoden des entsprechenden Typs, deren Arithmetik mit den angegebenen Typargumenten übereinstimmt und die Einschränkungen mit den angegebenen Typargumenten erfüllen, im Set enthalten, wenn sie statisch sind und der Empfänger ein Typ ist, oder wenn sie nicht statisch sind und der Empfänger ein Wert ist
  • für nachfolgende Bereiche sind Erweiterungsmethoden in diesem Bereich, die mit den bereitgestellten Typargumenten ersetzt und mit dem Wert des Empfängers reduziert werden können, während sie die Einschränkungen erfüllen, im Set enthalten
  1. Wenn im angegebenen Bereich keine Kandidaten vorhanden sind, fahren Sie mit dem nächsten Bereich fort.
  2. Wenn die Signaturen aller Kandidaten nicht übereinstimmen, hat die Methodengruppe keinen natürlichen Typ.
  3. Andernfalls wird die resultierende Signatur als natürlicher Typ verwendet.
  4. Wenn die Bereiche erschöpft sind, dann hat die Methodengruppe keinen natürlichen Typ

Bezieht sich auf den Vorschlag Bereich für Bereich: https://github.com/dotnet/csharplang/issues/7364 Bezieht sich auf den Vorschlag, generische Erweiterungsmethoden besser zu behandeln: https://github.com/dotnet/roslyn/issues/69222