Mads Torgersen, C# Lead Designer, .NET Team, a annoncé la disponibilité de C# 11.Littéraux de chaîne UTF-8
Par défaut, les chaînes C# sont codées en dur en UTF-16, alors que l'encodage de chaîne en vigueur sur Internet est UTF-8. Pour minimiser les tracas et la surcharge de performances liés à la conversion, vous pouvez désormais simplement ajouter un suffixe u8 à vos littéraux de chaîne pour les obtenir immédiatement en UTF-8*:
| Code C# : | Sélectionner tout |
var u8 = "This is a UTF-8 string!"u8;
Les littéraux de chaîne UTF-8 vous renvoient simplement un bloc d'octets - sous la forme d'un ReadOnlySpan<byte>. Pour les scénarios où il est important d'avoir un encodage UTF-8, cela est probablement plus utile qu'un nouveau type de chaîne UTF-8 dédié.
Littéraux de chaîne bruts
Une grande partie de ce qui est mis dans les littéraux de chaîne est du « code » quelconque - pas seulement du texte de programme, mais aussi des données JSON et XML, du HTML, des expressions régulières, des requêtes SQL, etc. C'est vraiment inutile lorsque de nombreux caractères spéciaux qui s'affichent dans un tel texte ont une signification particulière dans les littéraux de chaîne C#*! Des exemples remarquables incluent \ et ", joints dans des chaînes interpolées par { et }. Devoir échapper à tout cela est une vraie déception et une source permanente de douleur et de bogues.
Pourquoi ne pas avoir une forme de littéraux de chaîne qui n'a aucun caractère d'échappement*? C'est ce que sont les littéraux de chaîne bruts. Tout est contenu !
Un littéral de chaîne brut est délimité par au moins trois guillemets*:
| Code C# : | Sélectionner tout |
1 2 | var raw1 = """This\is\all "content"!"""; Console.WriteLine(raw1); |
Cela affiche*:
Envoyé par affichage à l'écranThis\is\all "content"!
| Code C# : | Sélectionner tout |
var raw2 = """""I can do ", "", """ or even """" double quotes!""""";
Il est ainsi très facile de coller, de maintenir et de lire en un coup d'œil ce que contient le littéral.
Les littéraux de chaîne bruts multilignes peuvent également tronquer l'espace blanc de début*: la position du guillemet final détermine où l'espace blanc commence à être inclus dans la sortie*:
| Code C# : | Sélectionner tout |
1 2 3 4 5 6 7 8 | var raw3 = """ <element attr="content"> <body> This line is indented by 4 spaces. </body> </element> """; // ^white space left of here is removed |
Puisqu'il y a quatre espaces à gauche du guillemet de fin, quatre espaces seront supprimés au début de chaque ligne de contenu, ce qui donnera cette sortie*:
Envoyé par Affichage à l'écran<element attr="content">
<body>
This line is indented by 4 spaces.
</body>
</element>
<body>
This line is indented by 4 spaces.
</body>
</element>
Les membres requis vous permettent d'écrire des types de classe et de structure qui nécessitent que les appelants définissent certaines propriétés. Considérez ce type Person :
| Code C# : | Sélectionner tout |
1 2 3 4 5 | public class Person { public string FirstName { get; init; } public string LastName {get; init; } } |
Les appelants doivent utiliser des initialiseurs d'objet pour définir les valeurs des propriétés FirstName et LastName. Mais avant la version 17.3, le compilateur ne pouvait pas obliger les appelants à définir ces propriétés. Un constructeur qui requiert des paramètres est le seul moyen de s'assurer que l'utilisateur définit les propriétés FirstName et LastName. Les membres requis indiquent au compilateur et aux appelants qu'ils doivent définir ces propriétés. Ajoutez le modificateur requis aux déclarations de membre :
| Code C# : | Sélectionner tout |
1 2 3 4 5 | public class Person { public required string FirstName { get; init; } public required string LastName {get; init; } } |
Tous les appelants doivent inclure des initialiseurs d'objet pour les propriétés FirstName et LastName, sinon le compilateur émet une erreur. Le compilateur informe les appelants que les membres requis n'ont pas été initialisés. Le développeur doit résoudre le problème immédiatement.
Si le type Person a été écrit pour une version antérieure et inclut un constructeur qui définit les propriétés, vous pouvez toujours utiliser les membres requis. Vous devez annoter tous les constructeurs existants avec l'attribut SetsRequiredMembers :
| Code C# : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | public class Person { public required string FirstName { get; init; } public required string LastName {get; init; } [SetsRequiredMembers] public Person(string firstName, string lastName) { this.FirstName = firstName; this.LastName = lastName; } public Person() {} } |
L'attribut SetsRequiredMembers indique qu'un constructeur définit tous les membres requis. Le compilateur sait que les appelants utilisant le constructeur Person(string firstName, string lastName), on défini les membres requis. Le constructeur sans paramètre n'inclut pas cet attribut, donc les appelants utilisant ce constructeur doivent initialiser tous les membres requis à l'aide des initialiseurs d'objet.
Les exemples ci-dessus utilisaient des propriétés, mais vous pouvez également appliquer les membres requis aux déclarations de champ.
Cette version contient également une implémentation initiale des champs ref et des valeurs délimitées. Ces modifications permettent d'utiliser les champs ref dans les types de structures ref. Vous pouvez également utiliser le mot-clé scoped pour limiter la durée de vie des paramètres ref. La proposition de fonctionnalité et les modifications mises à jour fournissent actuellement la meilleure documentation sur cette fonctionnalité. Nous avons découvert certains scénarios qui nécessitaient des changements de langue pour être utilisés en toute sécurité.
Support mathématique générique
Microsoft a ajouté des fonctionnalités où le scénario motivant était les mathématiques génériques. Vous n'utiliserez ces fonctionnalités directement que dans des scénarios avancés, tels que l'écriture d'algorithmes mathématiques qui fonctionnent sur plusieurs types de nombres. Sinon, vous en bénéficierez indirectement car l'environnement d'exécution utilise ces fonctionnalités.
L'ajout de membres statiques abstraits et virtuels dans les interfaces fournit une grande partie de l'infrastructure importante pour les mathématiques génériques. Cette fonctionnalité permet aux interfaces de déclarer des opérateurs ou d'autres méthodes statiques. Les classes qui implémentent une interface doivent fournir l'implémentation de méthodes abstraites statiques, tout comme les autres méthodes déclarées dans les interfaces. Le compilateur résout les appels aux méthodes statiques, y compris les opérateurs, au moment de la compilation. Il n'y a pas de mécanisme de répartition d'exécution comme c'est le cas avec les méthodes d'instance. Les documents fournissent plus de détails sur les règles de langage spécifiques requises pour faire fonctionner cette fonctionnalité.
D'autres fonctionnalités du langage atténuent certaines différences dans les types numériques pour faciliter l'écriture d'algorithmes mathématiques génériques. L'opérateur de décalage vers la droite n'exige plus que le deuxième opérande soit un entier. N'importe quel type intégral fera l'affaire ! Les types nint et nuint sont respectivement synonymes de System.IntPtr et System.UIntPtr. Ces mots-clés peuvent être utilisés à la place de ces types. En fait, de nouveaux analyseurs vous pousseront doucement à préférer les mots-clés aux noms de type. Enfin, l'opérateur de décalage à droite non signé (>>>) évite les transtypages lorsque vous effectuez un décalage non signé.
Combinés, ces changements et d'autres changements comme les opérateurs cochés prennent en charge les changements d'exécution mathématiques génériques. Les améliorations du langage signifient que l'équipe d'exécution peut apporter des améliorations à tous les types numériques dans .NET. Vous pouvez également tirer parti des fonctionnalités lorsque vos types implémentent des contrats à l'aide d'opérateurs ou d'autres méthodes statiques.
Autoriser les nouvelles lignes dans les "trous" des chaînes interpolées
C# supporte deux styles de chaînes interpolées : les chaînes interpolées verbatim et non verbatim ($@"" et $"", respectivement). Selon Kathleen Dollard de Microsoft, l'une des principales différences entre ces deux types de chaînes est qu'une chaîne interpolée non verbatim ne peut pas contenir de nouvelles lignes dans ses segments de texte et doit utiliser des échappatoires (comme rn). Une chaîne interpolée verbatim peut contenir de nouvelles lignes dans ses segments de texte, et n'échappe pas les nouvelles lignes ou tout autre caractère (à l'exception de "" pour échapper à une citation elle-même). Tout ce comportement reste le même.
Auparavant, ces restrictions s'étendaient aux trous des chaînes interpolées non verbatim. Les trous sont une façon abrégée de dire "expressions d'interpolation" et sont les portions à l'intérieur des accolades qui fournissent des valeurs d'exécution. Les trous eux-mêmes ne sont pas du texte, et ne doivent pas être soumis aux règles d'échappement/saut de ligne des segments de texte de la chaîne interpolée. Par exemple, l'exemple suivant aurait entraîné une erreur de compilation en C# 10, mais est autorisé dans C# 11 :
| Code C# : | Sélectionner tout |
1 2 3 4 | var v = $"Count ist: { this.Is.Really.Something() .That.I.Should( be + able)[ to.Wrap()] }."; |
Les motifs de liste (List patterns)
Selon l'équipe C#, le nouveau motif de liste vous permet d'établir des correspondances avec des listes et des tableaux. Vous pouvez faire correspondre des éléments et éventuellement inclure un motif de tranche qui correspond à zéro ou plusieurs éléments. En utilisant les motifs de tranche, vous pouvez écarter ou capturer zéro ou plusieurs éléments. La syntaxe des motifs de liste est constituée de valeurs entourées de crochets et celle des motifs de tranche de deux points. Le motif de tranche peut être suivi d'un autre motif de liste pour capturer le contenu de la tranche.
Le motif [1, 2, ..., 10] correspond à tous les éléments suivants :
| Code C# : | Sélectionner tout |
1 2 3 | int[] arr1 = { 1, 2, 10 }; int[] arr1 = { 1, 2, 5, 10 }; int[] arr1 = { 1, 2, 5, 6, 7, 8, 9, 10 }; |
Pour explorer les modèles de liste, considérez :
| Code C# : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | public static int CheckSwitch(int[] values) => values switch { [1, 2, .., 10] => 1, [1, 2] => 2, [1, _] => 3, [1, ..] => 4, [..] => 50 }; |
Lorsqu'on lui passe les tableaux suivants, les résultats sont ceux indiqués :
| Code C# : | Sélectionner tout |
1 2 3 4 5 6 | WriteLine(CheckSwitch(new[] { 1, 2, 10 })); // prints 1 WriteLine(CheckSwitch(new[] { 1, 2, 7, 3, 3, 10 })); // prints 1 WriteLine(CheckSwitch(new[] { 1, 2 })); // prints 2 WriteLine(CheckSwitch(new[] { 1, 3 })); // prints 3 WriteLine(CheckSwitch(new[] { 1, 3, 5 })); // prints 4 WriteLine(CheckSwitch(new[] { 2, 5, 6, 7 })); // prints 50 |
Vous pouvez également capturer les résultats d'un motif de tranche :
| Code C# : | Sélectionner tout |
1 2 3 4 5 6 | public static string CaptureSlice(int[] values) => values switch { [1, .. var middle, _] => $"Middle {String.Join(", ", middle)}", [.. var all] => $"All {String.Join(", ", all)}" }; |
Les motifs de liste fonctionnent avec tout type qui est dénombrable et indexable, ce qui signifie qu'il possède une propriété Length ou Count accessible et un indexeur avec un paramètre int ou System.Index. Les modèles de tranche fonctionnent avec tout type qui est dénombrable et "tranchable", ce qui signifie qu'il a un indexeur accessible qui prend un Range comme argument ou a une méthode Slice accessible avec deux paramètres int. L'équipe envisage également d'ajouter la prise en charge des motifs de liste pour les types IEnumerable.
Vérification des paramètres null
Selon l'équipe responsable du développement de C#, il y a eu des discussions sur une syntaxe très succincte par rapport à une syntaxe plus verbeuse. « Nous voulons obtenir les commentaires des clients et des utilisateurs qui ont eu la chance d'expérimenter cette fonctionnalité », a-t-elle déclaré. Il est assez courant de valider si les arguments d'une méthode sont null avec des variations de code passe-partout comme :
| Code C# : | Sélectionner tout |
1 2 3 4 5 6 7 8 | public static void M(string s) { if (s is null) { throw new ArgumentNullException(nameof(s)); } // Body of the method } |
Avec la vérification des paramètres null, vous pouvez abréger votre intention en ajoutant !! au nom du paramètre :
| Code C# : | Sélectionner tout |
1 2 3 4 | public static void M(string s!!) { // Body of the method } |
Ainsi, du code sera généré pour effectuer le contrôle de nullité. Le contrôle de nullité généré sera exécuté avant tout code de la méthode. Pour les constructeurs, la vérification des paramètres null se produit avant l'initialisation du champ, les appels aux constructeurs de base et les appels à ce constructeur. De plus, l'équipe a déclaré que cette fonctionnalité est indépendante des types de référence nullable (NRT - Nullable Reference Types), bien qu'elles fonctionnent bien ensemble. NRT vous aide à savoir, au moment de la conception, si un null est possible.
La vérification des paramètres null permet de vérifier plus facilement, au moment de l'exécution, si des valeurs null ont été transmises à votre code. Ceci est particulièrement important lorsque votre code interagit avec du code externe qui peut ne pas avoir de NRT activé. La vérification est similaire à if (param is null) throw new ArgumentNullException(...). Lorsque plusieurs paramètres contiennent l'opérateur !!, les vérifications sont effectuées dans l'ordre de déclaration des paramètres. Il existe quelques directives limitant l'utilisation de l'opérateur !!, notamment :
- les contrôles de nullité ne peuvent être appliqués aux paramètres que lorsqu'il existe une implémentation. Par exemple, un paramètre de méthode abstraite ne peut pas utiliser !!. Parmi les autres cas où il ne peut pas être utilisé, citons : les paramètres de méthodes externes, les paramètres des délégués, les paramètres des méthodes d'interface lorsque la méthode n'est pas une méthode d'interface par défaut (DIM - Default Interface Method) ;
- les contrôles de nullité ne peuvent être appliqués qu'aux paramètres qui peuvent être vérifiés.
Les paramètres de rejet et de sortie sont un exemple de scénarios exclus en vertu de la deuxième règle. Le contrôle des valeurs null peut être effectué sur les paramètres ref et in. La vérification du caractère null est autorisée pour les paramètres de l'indexeur, et la vérification est ajoutée à l'accesseur get et set. Par exemple :
| Code C# : | Sélectionner tout |
public string this[string key!!] { get { ... } set { ... } }
Les contrôles de nullité peuvent être utilisés sur les paramètres lambda, qu'ils soient ou non entourés de parenthèses :
| Code C# : | Sélectionner tout |
1 2 | // An identity lambda which throws on a null input Func<string, string> s = x!! => x; |
Les méthodes asynchrones peuvent avoir des paramètres vérifiés comme null. La vérification de la nullité a lieu lorsque la méthode est invoquée. La syntaxe est également valable pour les paramètres des méthodes d'itération. La vérification du caractère null se produit lorsque la méthode de l'itérateur est invoquée, et non lorsque l'énumérateur sous-jacent est parcouru. Ceci est vrai pour les itérateurs traditionnels ou asynchrones :
| Code C# : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 | class Iterators { IEnumerable<char> GetCharacters(string s!!) { foreach (var c in s) { yield return c; } } void Use() { // The invocation of GetCharacters will throw IEnumerable<char> e = GetCharacters(null); } } |
Interaction avec les types de référence null
Tout paramètre dont le nom est accompagné de l'opérateur !! commencera avec l'état nullable, c'est-à-dire non null. Ceci est vrai même si le type du paramètre lui-même est potentiellement null. Cela peut se produire avec un type explicitement nullable, comme string?, ou avec un paramètre de type non contraint. Lorsque la syntaxe !! sur les paramètres est combinée avec un type explicitement nullable sur le paramètre, le compilateur émet un avertissement :
| Code C# : | Sélectionner tout |
1 2 3 4 | void WarnCase<T>( string? name!!, // CS8995 Nullable type 'string?' is null-checked and will throw if null. T value1!! // Okay ) |
Constructeurs
Selon l'équipe, il y a un petit changement, mais observable, lorsque vous passez de contrôles de nullité explicites dans votre code à des contrôles de nullité utilisant la syntaxe de vérification des nullités (!!). Votre vérification explicite se produit après les initialiseurs de champ, les constructeurs de classe de base et les constructeurs appelés à l'aide de ceci. Les contrôles de nullité effectués avec la syntaxe de contrôle de nullité des paramètres se produiront avant l'exécution de l'un de ces éléments.
Source : Microsoft
Voir aussi
Microsoft annonce la sortie de C# 10 dans le cadre de .NET 6 et Visual Studio 2022, C# 10 apporte des améliorations aux expressions lambda et plusieurs fonctionnalités ReSharper 2021.3 est disponible avec la prise en charge de Visual Studio 2022, plus de fonctionnalités de C# 10, et un support amélioré des types de référence nullables et de C# Visual Studio 2022 Preview 4 est disponible et s'accompagne d'améliorations sur la productivité personnelle et d'équipe, le chargement à chaud dans ASP.NET Core et la gestion de thèmes Meilleurs langages de programmation en 2021 selon l'IEEE : Python leader pour la 5è année consécutive, il s'impose dans tous les domaines dans lesquels il est utilisé, du web à l'embarqué Visual Studio 2022 17.1 est maintenant disponible, et s'accompagne des améliorations dans Git, des améliorations de la productivité en C# et C++ 
