Pourquoi puis-je attribuer 0,0 aux valeurs d'énumération, mais pas 1,0

Juste par curiosité: pourquoi puis-je attribuer 0,0 à une variable de type énumération, mais pas 1,0? Jetez un œil au code suivant:

public enum Foo
{
    Bar,
    Baz
}

class Program
{
    static void Main()
    {
        Foo value1 = 0.0;
        Foo value2 = 1.0;   // This line does not compile
        Foo value3 = 4.2;   // This line does not compile
    }
}

Je pensais que les conversions entre les types numériques et les valeurs d'énumération ne sont autorisées que via des casts? C'est-à-dire que je pourrais écrire Foo value2 = (Foo) 1.0;pour que la ligne 2 Mainpuisse compiler. Pourquoi y a-t-il une exception pour la valeur 0.0en C #?

C'est un bogue que vous pouvez utiliser 0.0. Le compilateur traite implicitement toutes les expressions constantes avec une valeur de zéro comme juste 0.

Maintenant, il est correct que le compilateur autorise une conversion implicite d'une intexpression constante de 0 à votre enum selon la section 6.1.3 de la spécification C # 5:

Une conversion d'énumération implicite permet au décimal-entier-littéral 0 d'être converti en n'importe quel type enum et en n'importe quel type nullable dont le type sous-jacent est un type enum. Dans ce dernier cas, la conversion est évaluée en convertissant au type enum sous-jacent et en encapsulant le résultat (§4.1.10).

J'en ai déjà parlé avec l'équipe C #: ils auraient aimé supprimer la conversion accidentelle de 0,0 (et en fait 0,0 m et 0,0f) en valeurs enum, mais malheureusement, je suppose que cela a cassé trop de code - même si cela n'aurait jamais dû être autorisé en premier lieu.

Le Mono mcscompilateur interdit toutes ces conversions à virgule flottante, même si elle ne permet:

const int Zero = 0;
...

SomeEnum x = Zero;

malgré le fait que ce Zerosoit une expression constante mais pas un entier décimal.

Je ne serais pas surpris de voir la spécification C # changer à l'avenir pour autoriser toute expression constante entière avec une valeur de 0 (c'est-à-dire imiter mcs), mais je ne m'attendrais pas à ce que les conversions en virgule flottante soient officiellement correctes. (Je me suis trompé avant de prédire l'avenir de C #, bien sûr ...)

La réponse de Jon est correcte. J'y ajouterais les points suivants.

• J'ai causé ce bug stupide et embarrassant. Beaucoup d'excuses.

• Le bogue a été causé par une mauvaise compréhension de la sémantique d'un prédicat «expression is zero» dans le compilateur; Je pensais qu'il ne vérifiait que l'égalité des entiers zéro, alors qu'en fait, il en recherchait plus du type "est-ce la valeur par défaut de ce type?" En fait, dans une version antérieure du bogue, il était en fait possible d'attribuer la valeur par défaut de n'importe quel type à une énumération! Il ne s'agit désormais que des valeurs par défaut des nombres. (Leçon: Nommez soigneusement vos prédicats d'assistance.)

• Le comportement que j'essayais d'implémenter et que j'avais foiré était en fait une solution de contournement pour un bogue légèrement différent. Vous pouvez lire toute la terrible histoire ici: https://docs.microsoft.com/en-us/archive/blogs/ericlippert/the-root-of-all-evil-part-one et https://docs.microsoft .com / fr-fr / archive / blogs / ericlippert / the-root-of-all-evil-part-two (Leçon: Il est très facile d'introduire de nouveaux bogues pires tout en corrigeant les anciens.)

• L'équipe C # a décidé de consacrer ce comportement bogué plutôt que de le corriger car le risque de casser le code existant sans avantage convaincant était trop élevé. (Leçon: faites les choses correctement du premier coup!)

• Le code que j'ai écrit dans Roslyn pour préserver ce comportement se trouve dans la méthode IsConstantNumericZeroen https://github.com/dotnet/roslyn/blob/master/src/Compilers/CSharp/Portable/Binder/Semantics/Conversions/ConversionsBase.cs - voyez-le pour plus de détails sur ce qu'est exactement le comportement de Roslyn. J'ai écrit presque tout le code dans le répertoire Conversions; Je vous encourage à tout lire car il y a de nombreux faits intéressants sur la façon dont C # diverge de la spécification dans les commentaires. J'ai décoré chacun avec SPEC VIOLATION pour les rendre faciles à trouver.

Un autre point d'intérêt: C # permet également d'utiliser n'importe quelle valeur d'énumération dans un initialiseur d'énumération indépendamment de son zéro:

enum E { A = 1 }
enum F { B = E.A }  // ???

La spécification est quelque peu vague quant à savoir si cela devrait être légal ou non, mais encore une fois, comme cela est dans le compilateur depuis longtemps, les nouveaux compilateurs sont susceptibles de maintenir le comportement.

Les énumérations en C # sont par définition des valeurs intégrales. Par souci de cohérence, C # ne doit accepter aucune de ces affectations, mais 0.0est traité silencieusement comme intégrale 0. C'est probablement un héritage de C, où le littéral a 0été traité spécialement et pourrait essentiellement prendre n'importe quel type donné - entier, nombre à virgule flottante, pointeur nul… vous le nommez.

enum est vraiment destiné (dans toutes les langues qui le supportent) à être un moyen de travailler avec des chaînes significatives et uniques (étiquettes) plutôt que des valeurs numériques. Ainsi, dans votre exemple, vous ne devez utiliser Bar et Baz que pour un type de données énuméré Foo . Vous ne devriez jamais utiliser (comparer ou affecter) un entier, même si de nombreux compilateurs vous permettront de vous en sortir (les énumérations sont généralement entiers en interne), et dans ce cas, un 0.0 est traité négligemment comme un 0 par le compilateur.

Conceptuellement, il devrait être correct d'ajouter un entier n à une valeur énumérée, pour obtenir n valeurs plus loin dans la ligne, ou de prendre val2 - val1 pour voir à quelle distance ils sont, mais à moins que la spécification du langage ne le permette explicitement, je Je l'éviterais. (Pensez à une valeur énumérée comme étant comme un pointeur C, de la manière dont vous pouvez l'utiliser.) Il n'y a aucune raison pour laquelle les énumérations ne peuvent pas être implémentées avec des nombres à virgule flottante, et un incrément fixe entre eux, mais je n'en ai pas entendu parler ceci étant fait dans n'importe quelle langue.