Delen via

Verbeteringen aan natuurlijke type methodengroep

  • Artikel

Notitie

Dit artikel is een functiespecificatie. De specificatie fungeert als het ontwerpdocument voor de functie. Het bevat voorgestelde specificatiewijzigingen, samen met informatie die nodig is tijdens het ontwerp en de ontwikkeling van de functie. Deze artikelen worden gepubliceerd totdat de voorgestelde specificaties zijn voltooid en opgenomen in de huidige ECMA-specificatie.

Er kunnen enkele verschillen zijn tussen de functiespecificatie en de voltooide implementatie. Deze verschillen worden vastgelegd in de relevante LDM-notities (Language Design Meeting).

Meer informatie over het proces voor het aannemen van functiespeclets in de C#-taalstandaard vindt u in het artikel over de specificaties.

Probleem met kampioen: https://github.com/dotnet/csharplang/issues/7429

Samenvatting

In dit voorstel wordt de bepaling van het natuurlijke type methodegroep op een aantal manieren verfijnd:

  1. Overweeg kandidaatmethoden van scope tot scope (eerst instantiemethoden, en vervolgens elke volgende scope van uitbreidingsmethoden)
  2. Verwijder kansloze kandidaten om te voorkomen dat ze interfereren met het bepalen van een unieke signatuur.
    • Algemene exemplaarmethoden verwijderen wanneer er geen typeargumenten worden opgegeven (var x = M;)
    • Algemene uitbreidingsmethoden snoeien op basis van het kunnen verminderen van de extensie en van beperkingen

Context voor het natuurlijk type van de methodegroep

In C# 10 kregen methodegroepen een zwak natuurlijk type.
Dat type is een "zwak type" dat alleen in het spel komt wanneer de methodegroep niet doelgericht getypeerd is (dat wil zeggen, het speelt geen rol in System.Action a = MethodGroup;).
Dat zwakke natuurlijke type maakt scenario's zoals var x = MethodGroup;mogelijk.

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

Een methodegroep heeft een natuurlijk type als alle kandidaatmethoden in de methodegroep een gemeenschappelijke handtekening hebben. (Als de methodegroep uitbreidingsmethoden kan bevatten, bevatten de kandidaten het bijbehorende type en alle uitbreidingsmethodebereiken.)

In de praktijk betekent dit dat we:

  1. Stel de set van alle kandidaatmethoden samen:
  • methoden voor het relevante type bevinden zich in de set als ze statisch zijn en de ontvanger een type is, of als ze niet statisch zijn en de ontvanger een waarde is
  • uitbreidingsmethoden (voor alle bereiken) die kunnen worden verkleind, bevinden zich in de set
  1. Als de handtekeningen van alle kandidaten niet overeenkomen, heeft de methodegroep geen natuurlijk type
  2. Als de ariteit van de resulterende handtekening niet overeenkomt met het aantal opgegeven typeargumenten, heeft de methodegroep geen natuurlijk type
  3. Anders wordt de resulterende handtekening gebruikt als het natuurlijke type

Voorstel

Het principe is om scope-by-scope te gaan en kandidaten te verwijderen die we kennen, niet zo vroeg mogelijk kunnen slagen (hetzelfde principe dat wordt gebruikt in overbelastingsresolutie).

  1. Voor elk bereik maken we de set van alle kandidaatmethoden:
  • Voor het initiële bereik behoren methoden van het relevante type met een ariteit die overeenkomt met de opgegeven typeargumenten en die voldoen aan de beperkingen met de opgegeven typeargumenten tot de set als ze statisch zijn en de ontvanger een type is, of als ze niet statisch zijn en de ontvanger een waarde is.
  • voor daaropvolgende bereiken bevinden uitbreidingsmethoden in dat bereik die kunnen worden vervangen door de opgegeven typeargumenten, en met behulp van de waarde van de ontvanger kunnen worden gereduceerd terwijl de voorwaarden worden nageleefd, zich in de set.
  1. Als we geen kandidaten in het opgegeven bereik hebben, gaat u verder met het volgende bereik.
  2. Als de handtekeningen van alle kandidaten niet overeenkomen, heeft de methodegroep geen natuurlijk type
  3. Anders wordt de resulterende handtekening gebruikt als het natuurlijke type
  4. Als de scopes zijn uitgeput, heeft de methodegroep geen natuurlijk type.

Betreft voorstel per specifiek bereik: https://github.com/dotnet/csharplang/issues/7364 Betreft voorstel om generieke uitbreidingsmethoden beter te beheren: https://github.com/dotnet/roslyn/issues/69222