Dela via

Förbättringar av naturliga typer för metodgrupper

  • Artikel

Not

Den här artikeln är en funktionsspecifikation. Specifikationen fungerar som designdokument för funktionen. Den innehåller föreslagna specifikationsändringar, tillsammans med information som behövs under utformningen och utvecklingen av funktionen. Dessa artiklar publiceras tills de föreslagna specifikationsändringarna har slutförts och införlivats i den aktuella ECMA-specifikationen.

Det kan finnas vissa skillnader mellan funktionsspecifikationen och den slutförda implementeringen. Dessa skillnader noteras i de relevanta anteckningarna från Language Design Meeting (LDM) .

Du kan läsa mer om processen för att införa funktionsspecifikationer i C#-språkstandarden i artikeln om specifikationerna.

Champion-problem: https://github.com/dotnet/csharplang/issues/7429

Sammanfattning

Detta förslag förfinar bestämningen av den naturliga typen av en metodgrupp på några sätt:

  1. Överväg kandidatmetoder för varje område och börja med instansmetoder, följt av varje efterföljande område för tilläggsmetoder.
  2. Beskär kandidater som inte har någon chans att lyckas, så att de inte stör fastställandet av en unik signatur.
    • Beskär generiska instansmetoder när inga typargument anges (var x = M;)
    • Beskär generiska metoder för tillägg utifrån möjligheten att minska tillägget och baserat på begränsningar.

Kontext för naturlig typ av metodgrupp

I C# 10 fick metodgrupper en svag naturlig typ.
Den typen är en "svag typ" eftersom den bara spelar in när metodgruppen inte är måltypad (dvs. den spelar ingen roll i System.Action a = MethodGroup;).
Den svaga naturliga typen tillåter scenarier som var x = MethodGroup;.

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

En metodgrupp har en naturlig typ om alla kandidatmetoder i metodgruppen har en gemensam signatur. (Om metodgruppen kan innehålla tilläggsmetoder, inkluderar kandidaterna den typ som innehåller och alla omfången för tilläggsmetoder.)

I praktiken innebär det att vi:

  1. Skapa uppsättningen med alla kandidatmetoder:
  • metoder för den relevanta typen finns i uppsättningen om de är statiska och mottagaren är en typ, eller om de är icke-statiska och mottagaren är ett värde
  • tilläggsmetoder (över alla omfång) som kan reduceras finns i mängden
  1. Om signaturerna för alla kandidater inte matchar har metodgruppen ingen naturlig typ
  2. Om den resulterande signaturens aritet inte matchar antalet angivna typargument har metodgruppen ingen naturlig typ
  3. Annars används den resulterande signaturen som den naturliga typen

Förslag

Principen är att gå igenom ett omfång i taget och eliminera kandidater som vi vet inte kan lyckas så tidigt som möjligt (samma princip används i överlagringslösning).

  1. För varje omfång skapar vi uppsättningen med alla kandidatmetoder:
  • För den ursprungliga omfattningen finns metoder för den relevanta typen vars aritet matchar de angivna typargumenten och uppfyller begränsningar i en uppsättning om de är statiska och mottagaren är en datatyp, eller om de är icke-statiska och mottagaren är ett värde.
  • för efterföljande områden i kodbasen finns tilläggsmetoder i det omfånget som kan ersättas med de angivna typargumenten och reduceras med mottagarens värde för att uppfylla begränsningarna inom uppsättningen
  1. Om vi inte har några kandidater i det angivna omfånget går du vidare till nästa omfång.
  2. Om signaturerna för alla kandidater inte matchar har metodgruppen ingen naturlig typ
  3. Annars används den resulterande signaturen som den naturliga typen
  4. Om omfången är uttömda har metodgruppen ingen naturlig typ

Relaterar till förslag från omfattning till omfattning: https://github.com/dotnet/csharplang/issues/7364 avser förslag för bättre hantering av generiska tilläggsmetoder: https://github.com/dotnet/roslyn/issues/69222