Pourquoi les instructions d'affectation renvoient-elles une valeur ?

Question

C'est autorisé :

int a, b, c;
a = b = c = 16;

string s = null;
while ((s = "Hello") != null) ;

D'après ce que j'ai compris, l'affectation s = ”Hello”; devrait seulement causer “Hello” à affecter à s mais l'opération ne devrait pas retourner de valeur. Si c'était vrai, alors ((s = "Hello") != null) produirait une erreur, puisque null ne serait comparé à rien.

Quel est le raisonnement qui permet aux instructions d'affectation de retourner une valeur ?

Answer 1

D'après ce que j'ai compris, l'affectation s = "Hello" ; devrait seulement provoquer l'affectation de "Hello" à s, mais l'opération ne devrait pas renvoyer de valeur.

Votre compréhension est 100% incorrecte. Pouvez-vous expliquer pourquoi vous croyez cette fausse chose ?

Quel est le raisonnement qui permet aux instructions d'affectation de retourner une valeur ?

Tout d'abord, l'affectation déclarations ne produisent pas de valeur. Affectation expressions produire une valeur. Une expression d'affectation est une déclaration légale ; il n'y a qu'une poignée d'expressions qui sont des déclarations légales en C# : les attentes d'une expression, la construction d'instances, l'incrémentation, la décrémentation, l'invocation et les expressions d'affectation peuvent être utilisées là où l'on attend une déclaration.

Il n'existe qu'un seul type d'expression en C# qui ne produit pas une valeur quelconque, à savoir une invocation de quelque chose qui est typée comme renvoyant void. (Ou, de manière équivalente, une attente d'une tâche sans valeur de résultat associée.) Tous les autres types d'expression produisent une valeur, une variable, une référence, un accès à une propriété ou à un événement, etc.

Remarquez que toutes les expressions qui sont légales en tant que déclarations sont utiles pour leurs effets secondaires . C'est le point clé ici, et je pense que c'est peut-être la cause de votre intuition que les affectations devraient être des déclarations et non des expressions. Idéalement, nous devrions avoir exactement un effet secondaire par instruction, et aucun effet secondaire dans une expression. C'est est il est un peu étrange que du code ayant un effet secondaire puisse être utilisé dans un contexte d'expression.

Le raisonnement derrière l'autorisation de cette fonctionnalité est que (1) elle est souvent pratique et (2) elle est idiomatique dans les langages de type C.

On pourrait noter que la question a été posée : pourquoi est-ce idiomatique dans les langages de type C ?

Malheureusement, Dennis Ritchie n'est plus disponible pour poser des questions, mais je pense qu'une mission laisse presque toujours derrière elle la valeur qui vient d'être attribuée dans un registre. Le C est un langage très "proche de la machine". Il semble plausible et conforme à la conception du C qu'il existe une caractéristique du langage qui signifie essentiellement "continuez à utiliser la valeur que je viens d'attribuer". Il est très facile d'écrire un générateur de code pour cette fonction ; il suffit de continuer à utiliser le registre qui a stocké la valeur qui a été assignée.

Answer 2

N'avez-vous pas fourni la réponse ? C'est pour permettre exactement le genre de constructions que vous avez mentionnées.

Un cas courant où cette propriété de l'opérateur d'affectation est utilisée est la lecture des lignes d'un fichier...

string line;
while ((line = streamReader.ReadLine()) != null)
    // ...

Answer 3

Mon utilisation préférée des expressions d'affectation est celle des propriétés initialisées paresseusement.

private string _name;
public string Name
{
    get { return _name ?? (_name = ExpensiveNameGeneratorMethod()); }
}

Answer 4

D'une part, il vous permet d'enchaîner vos affectations, comme dans votre exemple :

a = b = c = 16;

D'autre part, il vous permet d'assigner et de vérifier un résultat dans une seule expression :

while ((s = foo.getSomeString()) != null) { /* ... */ }

Ces deux raisons sont peut-être douteuses, mais il y a certainement des gens qui aiment ces constructions.

Answer 5

En dehors des raisons déjà mentionnées (enchaînement d'affectations, set-and-test dans les boucles while, etc. correctement utiliser le using déclaration que vous avez besoin de cette fonctionnalité :

using (Font font3 = new Font("Arial", 10.0f))
{
    // Use font3.
}

MSDN déconseille de déclarer l'objet jetable en dehors de l'instruction using, car il restera alors dans le champ d'application même après avoir été éliminé (voir l'article MSDN que j'ai cité).