Why null == false does not result in compile error in c#?

Question

This is not to solve any particular problem. Simply a compiler question.

Why does the following code not result in compile error? It's comparing a reference type to primitive type. Both null and false have to to be interpreted into something for the compiler to do comparison. Or is the parser simply scanning for such pattern and replace it with false?

if(null == false) { }

Value type or not, `false` is still an object. It will probably be boxed for the comparison. — cHao, May 04 '13 at 00:43
@cHao: Your conjecture is incorrect. The equality operator is specifically designed to avoid boxing; read the specification for details. — Eric Lippert, May 04 '13 at 14:41

Tejas Sharma · Accepted Answer · 2013-05-04T01:22:16.990

28

It's legal because the lifted comparison operator is used. If you compare a bool to a null, both the bool and null get implicitly converted to Nullable<bool> and the comparison operator for Nullable<bool> ends up being used. You get a warning because obviously, it is always false.

edited May 04 '13 at 01:22

answered May 04 '13 at 01:16

Tejas Sharma

3,420
22
35

4

I like your answer better, as it explains the _why_ it is allowed and _how_ it works. Instead of just stating the obvious. By the way, the compiler (in Debug-mode with optimizations off) doesn't even try to emit it. It simply emits `false` into the code. – Daniel A.A. Pelsmaeker May 04 '13 at 01:40
This is incorrect, per section 7.9.10 of the spec (equality operators and null). This explanation only applies in the case where, for `null == x`, `x` is a nullable type. The spec states this is equivalent to `x.HasValue`. Since the literal `false` is not a nullable type, the reason this is legal is not related to the lifted comparison operator. – drf May 04 '13 at 02:21
4

`false` might not be a nullable type, but it is of type `bool` and there is an implicit conversion between `bool` and `bool?` – Tejas Sharma May 04 '13 at 02:23
4

Also, here's a post by Eric Lippert on this topic http://stackoverflow.com/questions/1972262/c-sharp-okay-with-comparing-value-types-to-null – Tejas Sharma May 04 '13 at 02:24
5

This is the only correct answer posted. – Eric Lippert May 04 '13 at 14:46
As endorsed by Eric Lippert. ;-) – Chris May 04 '13 at 15:04

score 15 · Answer 2 · edited May 09 '13 at 05:23

Tejas's answer is correct. To more specifically address some of your points:

Why does the following code not result in compile error?

The question is not answerable; it does not produce an error because it is legal code, but that's a tautology.

If your question is actually "which section of the C# specification makes this legal?", then that's an answerable question. The section on lifted equality operators makes it legal.

It's comparing a reference type to primitive type.

It is not. First off, avoid the term "primitive type"; the specification does not clearly define it and it is not a useful concept in C#. You meant to say I think that it is comparing a value of reference type to a value of value type.

Second, that's not correct either. The null literal is not of reference type or value type; it is of no type. It is convertible to any nullable value type or any reference type, but it is of no type just by itself.

In this case the null literal is converted to the nullable bool type.

Both null and false have to be interpreted into something for the compiler to do comparison.

Correct. They are interpreted as nullable bools.

is the parser simply scanning for such pattern and replace it with false?

No, but that's an excellent guess. The compiler would constant-fold, say, true == false down to false, but it does not do folding optimizations that involve nullable value types. The language could be redesigned to support constant folding on operations with nullable value type operands; had nullable value types counterfactually been in version one, the proposed feature likely would have been supported.

@AndersForsgren: Was *what* comparison valid, in which version of C#? — Eric Lippert, May 09 '13 at 13:41
The comparison null==false, in the C# versions before nullable types were introduced in C# 2. That is: was it a compilation error in C# 1.2? — Anders Forsgren, May 09 '13 at 18:56
Found it I think. I interpret the spec as "yes it was": 7.9.6 *The predefined reference type equality operators do not permit value type operands to be compared.* — Anders Forsgren, May 09 '13 at 19:02
@AndersForsgren: That is correct; the predefined reference type equality operator would be the winner of overload resolution, and would then be disallowed because an operand was a value type. — Eric Lippert, May 09 '13 at 19:12

score 12 · Answer 3 · answered May 04 '13 at 02:15

12

Section 7.10.6 of the language specification (Reference type equality operators) states:

The x == null construct is permitted even though T could represent a value type, and the result is simply defined to be false when T is a value type.

This provision requires that null == false be false, and not a compiler error.

answered May 04 '13 at 02:15

drf

8,461
32
50

2

This section of the spec only applies to type parameters. – Eric Lippert May 04 '13 at 14:45

Why null == false does not result in compile error in c#?

3 Answers3