Why doesn't null evaluate to false?

Question

What is the reason null doesn't evaluate to false in conditionals?

I first thought about assignments to avoid the bug of using = instead of ==, but this could easily be disallowed by the compiler.

if (someClass = someValue) // cannot convert someClass to bool. Ok, nice

if (someClass) // Cannot convert someClass to bool. Why?

if (someClass != null) // More readable?

I think it's fairly reasonable to assume that null means false. There are other languages that use this too, and I've not had a bug because of it.

Edit: And I'm of course referring to reference types.

A good comment by Daniel Earwicker on the assignment bug... This compiles without a warning because it evaluates to bool:

bool bool1 = false, bool2 = true;
if (bool1 = bool2)
{
    // oops... false == true, and bool1 became true...
}

Answer 1

As far as I know, this is a feature that you see in dynamic languages, which C# is not (per the language specification if only accepts bool or an expression that evaluates to bool).

I don't think it's reasonable to assume that null is false in every case. It makes sense in some cases, but not in others. For example, assume that you have a flag that can have three values: set, unset, and un-initialized. In this case, set would be true, unset would be false and un-initialized would be null. As you can see, in this case the meaning of null is not false.

Answer 2

It's a specific design feature in the C# language: if statements accept only a bool.

IIRC this is for safety: specifically, so that your first if (someClass = someValue) fails to compile.

Edit: One benefit is that it makes the if (42 == i) convention ("yoda comparisons") unnecessary.

Answer 3

C# doesn't make a conversion of the parameter, as C++ does. You need to explicitly convert the value in a boolean, if you want the if statement to accept the value.

Answer 4

What is the reason null doesn't evaluate to false in conditionals?

I first thought about assignments to avoid the bug of using = instead of ==

That isn't the reason. We know this because if the two variables being compared happen to be of type bool then the code will compile quite happily:

bool a = ...
bool b = ...

if (a = b)
    Console.WriteLine("Weird, I expected them to be different");

If b is true, the message is printed (and a is now true, making the subsequent debugging experience consistent with the message, thus confusing you even more...)

The reason null is not convertible to bool is simply that C# avoids implicit conversion unless requested by the designer of a user-defined type. The C++ history book is full of painful stories caused by implicit conversions.

Answer 5

Structurally, most people who "cannot think of any technological reason null should be equal to false" get it wrong.

Code is run by CPUs. Most (if not all) CPUs have bits, groups of bits and interpretations of groups of bits. That said, something can be 0, 1, a byte, a word, a dword, a qword and so on.

Note that on x86 platform, bytes are octets (8 bits), and words are usually 16 bits, but this is not a necessity. Older CPUs had words of 4 bits, and even todays' low-end embedded controllers often use like 7 or 12 bits per word.

That said, something is either "equal", "zero", "greater", "less", "greater or equal", or "less or equal" in machine code. There is no such thing as null, false or true.

As a convention, true is 1, false is 0, and a null pointer is either 0x00, 0x0000, 0x00000000, or 0x0000000000000000, depending on address bus width.

C# is one of the exceptions, as it is an indirect type, where the two possible values 0 and 1 are not an immediate value, but an index of a structure (think enum in C, or PTR in x86 assembly).

This is by design.

It is important to note, though, that such design decisions are elaborate decisions, while the traditional, straightforward way is to assume that 0, null and false are equal.