Opérateur de rejet (_) en C# : quand il clarifie le code

L'opérateur discard _ en C# paraît simple. Il sert à ignorer une valeur dont on n'a pas besoin. Pourtant, comme beaucoup de petites fonctionnalités de langage, sa vraie valeur dépend du contexte.

Bien utilisé, il rend l'intention plus explicite. Mal utilisé, il cache une API mal pensée ou un manque de clarté dans le flux applicatif.

Ce que signifie vraiment _

Un discard indique une chose précise:

cette valeur existe, mais je choisis explicitement de ne pas l'utiliser.

Exemple:

if (int.TryParse(input, out _))
{
    // on ne garde pas la valeur, on valide seulement le format
}

Ici, _ rend l'intention très claire. On ne veut pas exploiter l'entier parse. On veut seulement savoir si le parsing réussit.

Les cas d'usage les plus utiles

1. Validation sans conservation de la valeur

Le cas le plus classique.

var isValid = Guid.TryParse(id, out _);

2. Déconstruction partielle

var (_, status, lastUpdated) = result;

Quand certaines informations ne servent pas, le discard evite d'introduire des variables inutiles.

3. Pattern matching

if (message is OrderCreated(_, var customerId, _))
{
    // seul customerId compte ici
}

Ce style fonctionne bien quand la structure est connue mais qu'une partie seulement du contenu est utile.

Pourquoi c'est utile

Le principal gain n'est pas de gagner quelques caractères. Le principal gain est de supprimer le bruit.

Au lieu d'écrire:

Guid ignored;
var ok = Guid.TryParse(id, out ignored);

on écrit directement l'intention:

var ok = Guid.TryParse(id, out _);

Moins de variables parasites, moins de confusion, moins de tentation de réutiliser une valeur sans vraie raison.

Quand le discard devient un mauvais signal

Le discard ne doit pas servir à masquer un problème de design.

Si tu te retrouves souvent à ignorer la moitié des valeurs retournées par une méthode, il faut te demander si le contrat est bien conçu.

Exemple douteux:

var (_, _, _, discountCode, _, _, _) = pricingResult;

Ce code compile, mais il crie surtout que la structure retournée n'est pas adaptée au besoin du consommateur.

Dans ce cas, mieux vaut:

• revoir le type de retour
• introduire un contrat plus cible
• simplifier l'API appelée

Discard et lisibilité

Le discard est utile tant qu'il rend la lecture plus simple. Il devient nuisible quand il oblige le lecteur à reconstruire mentalement des positions anonymes.

Par exemple, dans une déconstruction très longue, _ répété plusieurs fois peut nuire à la compréhension. Dans ce cas, un type nommé ou un accès par propriété reste souvent préférable.

Conclusion

L'opérateur _ en C# est une petite fonctionnalité, mais une bonne petite fonctionnalité: il rend explicite ce qu'on choisit de ne pas utiliser. Son meilleur usage consiste à clarifier l'intention. Son mauvais usage consiste à cacher un contrat ou une structure mal pensée.

Comme souvent, la question n'est pas "peut-on l'utiliser ?". La vraie question est: "est-ce que cela rend le code plus lisible ?"