Pourquoi l'opérateur is renvoie-t-il false lorsqu'il est donné null?

Il me semble que l' isopérateur est un peu incohérent.

bool Test()
{
    // Returns false, but should return true.
    return null is string;
}

On s'attend à ce que la nullvaleur appartienne à n'importe quel type référence (ou nullable). Et en effet, la spécification du langage C # dit quelque chose qui prend en charge cette hypothèse, par exemple (6.1.6 Conversions de référence implicites):

Les conversions de référence implicites sont les suivantes:
...
• Du littéral nul vers n'importe quel type de référence.

La description (7.10.10 L'opérateur is) de l' isopérateur commence par dire que l'expression (E is T)aboutira à vrai lorsqu'une conversion de référence de Eà Texiste, mais ensuite les auteurs continuent en excluant explicitement le cas où Eest le nulllittéral ou a une nullvaleur .

Pourquoi font-ils ça? Cela me semble contre-intuitif.

Cette question a fait l' objet de mon blog le 30 mai 2013 . Merci pour la bonne question!

Vous regardez une allée vide.

Quelqu'un vous demande "votre entrée peut-elle contenir une Honda Civic?"

Oui. Oui il peut.

Quelqu'un vous indique une deuxième allée. Il est également vide. Ils demandent "Le contenu actuel de mon entrée peut-il tenir dans votre entrée?"

Oui évidemment. Les deux allées sont vides! Il est donc clair que le contenu de l'un peut s'intégrer dans l'autre, car il n'y a pas de contenu de l'un ou l'autre en premier lieu.

Quelqu'un vous demande "Votre entrée contient-elle une Honda Civic?"

Non.

Vous pensez que l' isopérateur répond à la deuxième question: étant donné cette valeur, s'inscrit-elle dans une variable de ce type? Une référence nulle tient-elle dans une variable de ce type? Oui.

Ce n'est pas la question à laquelle isrépond l' opérateur. La question à laquelle l' isopérateur répond est la troisième question. y is Xne demande pas " est yune valeur légale d'une variable de type X? " Il demande " Une yréférence valide à un objet de type X? " Puisqu'une référence nulle n'est pas une référence valide à un objet de tout type, la réponse est "non ". Cette allée est vide; il ne contient pas de Honda Civic.

Une autre façon de voir les choses est que cela y is Xrépond à la question "si je disais y as X, est-ce que j'obtiendrai un résultat non nul? Si y est nul, la réponse est clairement non!

Pour approfondir votre question:

On s'attend à ce que la valeur nulle appartienne à n'importe quel type référence (ou nullable)

On supposerait implicitement qu'un type est un ensemble de valeurs , et que la compatibilité d'affectation d'une valeur y avec une variable de type X n'est ni plus ni moins que de vérifier si y est membre de l'ensemble x .

Bien que ce soit une façon extrêmement courante de regarder les types, ce n'est pas la seule façon de regarder les types, et ce n'est pas la façon dont C # regarde les types. Les références nulles sont des membres sans type en C #; la compatibilité d'affectation est pas simplement vérifier un ensemble pour voir si elle contient une valeur. Juste parce qu'une référence nulle est compatible avec l'affectation n'est pas avec une variable de type référence X que null est un membre de type X. La relation "est affectation compatible avec" et la relation "est membre de type" ont évidemment beaucoup de se chevauchent, mais ils ne sont pas identiques dans le CLR.

Si les réflexions sur la théorie des types vous intéressent, consultez mes articles récents sur le sujet:

Quelle est cette chose que vous appelez un «type»? Partie un

Quelle est cette chose que vous appelez un «type»? Deuxième partie

Je pense que null is stringretourner faux est très intuitif. Null ne signifie rien et ce n'est certainement pas une chaîne. Il devrait donc renvoyer false. Bien que ce soit un choix que les concepteurs de langage ont fait, il est très intuitif lorsque vous considérez la signification réelle de null.

Le nulllittéral peut être affecté à n'importe quel type de référence. Ce n'est pas un type en soi. C'est un littéral spécial qui représente une référence nulle.

Dans le cas où iscela reviendrait truequand un nullserait passé, que seriez-vous capable de faire avec le nulllittéral? Rien - ça l'est null. Quel serait l'intérêt de le faire revenir, truesauf pour des questions confuses?

Peu importe - en termes d'intuitivité, lisez le code en anglais et dites-moi:

null is string;

Quand je vois cela, cela semble poser la question is "nothing" a string?. Mon intuition me dit que non, ce n'est pas - c'est nothing.

http://msdn.microsoft.com/en-us/library/scekt9xw%28v=vs.71%29.aspx

Une expression is prend la valeur true si les deux conditions suivantes sont remplies:

• expression n'est pas nulle.
• l'expression peut être convertie en type. Autrement dit, une expression de conversion de la forme (type (expression) se terminera sans lever d'exception. Pour plus d'informations, voir 7.6.6 Expressions de conversion.

En pratique, avoir "null est T == false" m'évite de taper du code supplémentaire:

Au lieu d'avoir à dire

if (X != null && X is Foo) {}

Je peux juste dire

if (X is Foo) {}

et en finir.

la nullvaleur

Je l'ai cité à partir de votre question parce que cela semble aller au cœur du problème. null n'est pas une valeur - c'est l'absence de valeur. Le but de isme semble être de répondre à la question:

Si je lance Evers T, vais-je réussir à obtenir un T?

Maintenant, alors que vous pouvez jeter nullà T sans erreur , après avoir fait de sorte que vous ne « avez T» - vous avez encore rien obtenu. Donc ce n'est pas le cas où null"est" a T, donc isrenvoie false.

En Java il y a un opérateur qui fait exactement la même chose, mais il a beaucoup plus le nom: instanceof. C'est très intuitif là-bas qui null instanceof Stringrenvoie false, car null n'est une instance de rien, encore moins de a String. Donc, lors de l'utilisationnull la version de Java, c'est un peu plus intuitif.

Cependant, ces deux opérateurs renvoient true lorsqu'on leur demande de parcourir également toute la hiérarchie. Par exemple. si l'instance de Stringest un Object. Et ici, c'est Java qui est un peu moins intuitif (car une instance a en fait un type très spécifique) et C # isest plus intuitif (car tout String est unObject profond à l'intérieur).

Bottom line: si vous essayez de décrire une logique assez avancée en un mot, vous risquez d'avoir peu de gens confus, d'une manière ou d'une autre. Il semble que la plupart des gens étaient d'accord sur un sens et ceux qui n'étaient pas d'accord, ont dû s'adapter.