Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 notities van het taalontwerpoverleg (LDM).
Meer informatie over het proces voor het aannemen van functiespeclets in de C#-taalstandaard vindt u in het artikel over de specificaties.
Kampioensprobleem: https://github.com/dotnet/csharplang/issues/8645
Samenvatting
Versoepel de using_alias_directive (§13.5.2) zodat deze naar elk type kan verwijzen, niet alleen naar gespecificeerde typen. Dit biedt ondersteuning voor typen die momenteel niet zijn toegestaan, zoals tuple-typen, aanwijzertypen, matrixtypen, enzovoort. Dit is bijvoorbeeld nu toegestaan:
using Point = (int x, int y);
Motivatie
Al geruime tijd heeft C# de mogelijkheid om aliassen voor namespaces en benoemde typen (klassen, delegates, interfaces, records en structs) te introduceren. Dit heeft acceptabel gewerkt en het biedt een manier om niet-conflicterende namen te introduceren in gevallen waarin een normale benoemde pull-in van using_directives dubbelzinnig kan zijn en het een manier heeft toegestaan om een eenvoudigere naam te bieden bij het omgaan met complexe algemene typen. De opkomst van extra complexe typesymbolen in de taal heeft echter meer gebruik veroorzaakt wanneer aliassen waardevol zouden zijn, maar momenteel niet zijn toegestaan. Zowel tuples als functie-aanwijzers kunnen bijvoorbeeld vaak grote en complexe reguliere tekstvormen hebben die vervelend kunnen zijn om steeds weer uit te schrijven en moeilijk om te lezen. Aliassen helpen in deze gevallen door een korte, door ontwikkelaars verstrekte naam te geven die vervolgens kan worden gebruikt in plaats van die volledige structurele formulieren.
Gedetailleerd ontwerp
We zullen de grammatica van using_alias_directive zo wijzigen:
using_alias_directive
- : 'using' identifier '=' namespace_or_type_name ';'
+ : 'using' identifier '=' (namespace_name | type) ';'
;
Topniveau verwijzingstype null-baarheidsannotaties zijn niet toegestaan.
Interessant is dat de meeste specificatietaal in §13.5.2 niet hoeft te veranderen. In de meeste gevallen verwijst de taal hierin al naar 'naamruimte of type', bijvoorbeeld:
Een using_alias_directive introduceert een identificator die fungeert als een alias voor een naamruimte of type binnen de onmiddellijk omringende compilatie-eenheid of naamruimteblok.
Dit blijft waar, alleen dat de grammatica nu toestaat dat het type willekeurig is, niet de beperkte set die eerder door namespace_or_type_name is toegestaan.
De secties die wel moeten worden bijgewerkt, zijn:
- The order in which using_alias_directives are written has no significance, and resolution of the namespace_or_type_name referenced by a using_alias_directive is not affected by the using_alias_directive itself or by other using_directives in the immediately containing compilation unit or namespace body. In other words, the namespace_or_type_name of a using_alias_directive is resolved as if the immediately containing compilation unit or namespace body had no using_directives. A using_alias_directive may however be affected by extern_alias_directives in the immediately containing compilation unit or namespace body. In the example
+ The order in which using_alias_directives are written has no significance, and resolution of the `(namespace_name | type)` referenced by a using_alias_directive is not affected by the using_alias_directive itself or by other using_directives in the immediately containing compilation unit or namespace body. In other words, the `(namespace_name | type)` of a using_alias_directive is resolved as if the immediately containing compilation unit or namespace body had no using_directives. A using_alias_directive may however be affected by extern_alias_directives in the immediately containing compilation unit or namespace body. In the example
- The namespace_name referenced by a using_namespace_directive is resolved in the same way as the namespace_or_type_name referenced by a using_alias_directive. Thus, using_namespace_directives in the same compilation unit or namespace body do not affect each other and can be written in any order.
+ The namespace_name referenced by a using_namespace_directive is resolved in the same way as the namespace_or_type_name referenced by a using_alias_directive. Thus, using_namespace_directives in the same compilation unit or namespace body do not affect each other and can be written in any order.
+ It is illegal for a using alias type to be a nullable reference type.
1. `using X = string?;` is not legal.
2. `using X = List<string?>;` is legal. The alias is to `List<...>` which is itself not a nullable reference type itself, even though it contains one as a type argument.
3. `using X = int?;` is legal. This is a nullable *value* type, not a nullable *reference* type.
Ondersteunende aliassen voor typen die aanwijzers bevatten.
Er wordt een nieuwe onveilige context toegevoegd via een optioneel 'onveilig' trefwoord in de using_alias_directive productie:
using_alias_directive
+ : 'using' 'unsafe'? identifier '=' (namespace_name | type) ';'
;
using_static_directive
+ : 'using' 'static' 'unsafe'? type_name ';'
;
+ 'unsafe' can only be used with an using_alias_directive or using_static_directive, not a using_directive.
+ The 'unsafe' keyword present in a 'using_alias_directive' causes the entire textual extent of the 'type' portion (not the 'namespace_name' portion) to become an unsafe context.
+ The 'unsafe' keyword present in a 'using_static_directive' causes the entire textual extent of the 'type_name' portion to become an unsafe context.
C# feature specifications