Le nouveau mot-clé field en C# 14

La Configuration : Un Modèle de Personne Simple

[0:12 - 1:07] Tim commence avec une application console fonctionnant sur .NET 10 et Visual Studio 2026. La démo se concentre sur une classe Person avec quelques propriétés :

public required string FirstName { get; set; }
public required string LastName { get; set; }
public int Age { get; set; }

public required string FirstName { get; set; }
public required string LastName { get; set; }
public int Age { get; set; }

Il existe également une propriété Demo soutenue par un champ privé, qui devient pertinente une fois que le conflit de nommage émerge. Dans Program.cs, Tim crée une instance avec FirstName = "Tim" et LastName = "Corey", puis affiche le nom de famille, l'âge et la valeur de la démo. Tout s'affiche comme prévu : "Corey", 0 (l'entier par défaut), et "test".

Le Problème : Les Auto-Propriétés Acceptent les Mauvaises Données

[1:23 - 2:49] Le problème apparaît lorsque Tim affecte null à LastName après la construction :

p.LastName = null;

p.LastName = null;

Même si LastName est marqué required et typé comme une chaîne non nullable, l'affectation se compile. Le modificateur required n'impose que qu'une valeur soit fournie lors de l'initialisation de l'objet ; il n'empêche pas quelqu'un de définir la propriété à null par la suite. Le résultat est un nom de famille vide à l'exécution sans erreur lancée.

C'est une véritable lacune dans l'intégrité des données. Le système de type vous avertit avec une référence nullable, mais c'est une indication à la compilation, pas une garde à l'exécution. Si votre application dépend de LastName contenant toujours une chaîne valide, les propriétés automatiques seules ne peuvent pas faire respecter ce contrat.

La Solution Ancienne : Propriétés Complètes avec Champs de Soutien Manuels

[2:58 - 4:19] Avant C# 14, la solution standard consistait à convertir l'auto-propriété en une propriété complète avec un champ de soutien explicite :

private string _lastName;
public required string LastName
{
    get => _lastName;
    set => _lastName = value ?? throw new ArgumentNullException(nameof(LastName));
}

private string _lastName;
public required string LastName
{
    get => _lastName;
    set => _lastName = value ?? throw new ArgumentNullException(nameof(LastName));
}

Tim exécute cela et confirme que l'exception se déclenche correctement : "La valeur ne peut pas être nulle. Nom du paramètre : LastName." L'approche fonctionne, mais elle nécessite de déclarer un champ privé, de brancher à la fois le getter et le setter, et de répéter le nom de la propriété sur plusieurs lignes. Pour une seule règle de validation, c'est beaucoup de cérémonial.

Le getter dans ce cas ne fait rien de spécial ; il renvoie le champ inchangé. Pourtant, vous devez toujours l'écrire explicitement car la syntaxe exige les deux moitiés une fois que vous quittez le territoire de l'auto-propriété. Tim présente cette verbosité comme la motivation derrière la nouvelle fonctionnalité.

La Solution C# 14 : Le Mot-Clé field

[4:23 - 5:47] C# 14 introduit un juste milieu. Au lieu de déclarer vous-même un champ d'appui privé, vous utilisez le mot-clé contextuel field dans un getter ou setter pour référencer directement le champ d'appui généré par le compilateur :

public required string LastName
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(LastName));
}

public required string LastName
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(LastName));
}

Le getter reste un get; à mise en œuvre automatique sans corps requis. Le setter utilise field pour attribuer l'value entrant après validation. Le compilateur crée et gère le champ de soutien en coulisses, tout comme il le fait avec une auto-propriété standard.

Exécuter la démo produit le même ArgumentNullException lors d'une affectation nulle. Le comportement est identique à la version soutenue manuellement, compressée de sept lignes à un bloc concentré qui ne personnalise que ce qui nécessite une personnalisation. Vous gardez le getter de l'auto-propriété, ajoutez de la logique au seul setter, et évitez entièrement la déclaration de champ manuel.

Cela fournit une étape intermédiaire utile entre une auto-propriété simple (une ligne, pas de validation) et une propriété complète (sept lignes ou plus, contrôle total). Quand votre logique n'affecte que le setter, vous ne payez plus le coût syntaxique de réécrire le getter également.

Validation de l'Âge avec une Garde Setter

[6:16 - 7:39] Pour montrer que field n'est pas limité aux vérifications nulles, Tim ajoute une validation de plage à la propriété Age :

public int Age
{
    get;
    set
    {
        if (value > 0 && value < 120)
            field = value;
    }
}

public int Age
{
    get;
    set
    {
        if (value > 0 && value < 120)
            field = value;
    }
}

Ici, le setter ignore silencieusement les valeurs en dehors d'une plage raisonnable. Attribuer -5 laisse Age à sa valeur par défaut de zéro car la condition échoue et field n'est jamais écrit. Tim note que vous pourriez lancer une exception à la place, mais l'approche silencieuse démontre que le corps du setter peut contenir toute logique nécessaire tout en s'appuyant toujours sur field pour le stockage.

Le modèle s'applique à grande échelle : limiter les plages numériques, supprimer les espaces blancs des chaînes, normaliser la casse, ou toute transformation que vous souhaitez appliquer chaque fois qu'une propriété est définie.

Conflits de Noms avec les Variables field Existantes

[7:39 - 9:43] Tim introduit un cas limite délibéré. La classe de démo a un membre privé littéralement nommé field :

private string field = "test";

private string field = "test";

Une fois que C# 14 est actif, le compilateur traite field à l'intérieur d'un accessoire de propriété comme le mot-clé plutôt que la variable. Cela signifie qu'une propriété référant field lit en silence du stockage caché derrière la propriété (qui est vide) au lieu du membre chaîne contenant "test". La sortie devient vide sans erreur de compilation, seulement un avertissement.

Deux solutions existent. Le préfixage avec this.field indique au compilateur que vous voulez dire le membre au niveau de la classe, pas le mot-clé. Autrement, l'échappement @field fonctionne de la même manière :

// Both refer to the instance variable, not the keyword
string demo => this.field;
string demo => @field;

// Both refer to the instance variable, not the keyword
string demo => this.field;
string demo => @field;

La forte recommandation de Tim est de renommer toutes les variables appelées field lors de la mise à niveau vers C# 14. Un rapide "Renommer tout" dans votre IDE élimine définitivement l'ambiguïté. Le conflit ne survient qu'à l'intérieur des accesseurs de propriété ; les constructeurs et les méthodes résolvent field au nom de variable comme prévu, car ces contextes n'ont pas de stockage d'appui implicite.

Conclusion : Moins de Routine, Même Contrôle

[10:04 - 10:28] Le mot-clé field comble un vide pratique dans le code C# quotidien. Les propriétés qui nécessitent une clause de garde ou transformation ne nécessitent plus une réécriture complète avec des champs de soutien manuels. Vous personnalisez uniquement l'accesseur qui nécessite de la logique et laissez l'autre comme une implémentation auto-standard.

Conclusion

[10:28 - 10:35] Pour résumer : Le mot-clé field de C# 14 vous donne un accès direct au stockage d'appui implicite dans n'importe quel accessoire de propriété. Utilisez-le pour ajouter la validation de setter, des transformations getter, ou les deux, sans abandonner la syntaxe de l'auto-propriété pour les parties qui ne nécessitent pas de personnalisation.

Avant de mettre à niveau, recherchez dans votre base de code toutes les variables nommées field et renommez-les. Cette seule précaution évite la seule véritable surprise que cette fonctionnalité introduit. Au-delà de cela, c'est une réduction nette de la routine qui s'intègre naturellement à la façon dont la plupart des développeurs structurent déjà leurs modèles.

Astuce Exemple : Si vous n'avez besoin que de valider le setter, laissez le getter comme un get; simple sans corps. Le compilateur le traite comme un getter auto-propriété, et vous évitez d'écrire une instruction de retour par passage qui n'ajoute rien.

Regardez la vidéo complète sur sa chaîne YouTube et obtenez plus d'informations sur les fonctionnalités du langage C#.