Le nouveau mot-clé field en C# 14

La Configuration : Un Modèle de Personne Simple

[0:12 - 1:07] Tim commence par une application console fonctionnant sur .NET 10 et Visual Studio 2026. La démonstration 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 y a également une propriété Demo soutenue par un champ privé, ce qui devient pertinent une fois que le conflit de dénomination émerge. Dans Program.cs, Tim crée une instance avec FirstName = "Tim" et LastName = "Corey", puis imprime le nom de famille, l'âge et la valeur de démonstration. 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 assigne 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'assignation compile. Le modificateur required impose seulement qu'une valeur soit fournie lors de l'initialisation de l'objet; il ne prévient pas quelqu'un de définir ensuite la propriété à null. 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 auto-propriétés 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 de 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 de stockage privé, vous utilisez le mot-clé contextuel field dans un getter ou setter pour référencer directement le champ de stockage 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; implémenté automatiquement sans corps requis. Le setter utilise field pour assigner le 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.

L'exécution de la démonstration produit le même ArgumentNullException sur l'assignation null. 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 ne se limite pas 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 parce que la condition échoue et que 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 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émonstration 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 accesseur de propriété comme le mot-clé plutôt que comme la variable. Cela signifie qu'une propriété référencée field lit silencieusement à partir 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éfixe avec this.field indique au compilateur que vous pensez le membre au niveau de la classe, et non le mot-clé. Alternativement, 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 la variable comme prévu, puisque ces contextes n'ont pas de stockage implicite de sauvegarde.

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

[10:04 - 10:28] Le mot-clé field comble une lacune 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écapituler : le mot-clé field de C# 14 vous donne un accès direct à la mémoire de sauvegarde implicite à l'intérieur de n'importe quel accesseur 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 faire la mise à 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 avez seulement besoin de valider le setter, laissez le getter comme un simple get; 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#.