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

Because null and false are different things.

A perfect example is bool? foo

If foo's value is true, then its value is true.
If foo's value is false, then its value is false
If foo has nothing assigned to it, its value is null.

These are three logically separate conditions.

Think of it another way
"How much money do I owe you?"
"Nothing" and "I don't have that information" are two distinctly separate answers.

Answer 2

"I think it's fairly reasonable to assume that null means false"

Not in C#. false is a boolean struct, a value type. Value types cannot have a null value. If you wanted to do what you achieved, you'd have to create custom converters of your particular type to boolean:

public class MyClass
{
    public static implicit operator bool(MyClass instance)
    {
        return instance != null;
    }
}

With the above, I could then do:

if (instance) {

}

etc.

Answer 3

Just use if(Convert.ToBoolean(someClass))

http://msdn.microsoft.com/en-us/library/wh2c31dd.aspx

Parameters

value Type: System.Object An object that implements the IConvertible interface, or null. Return Value

Type: System.Boolean true or false, which reflects the value returned by invoking the IConvertible.ToBoolean method for the underlying type of value. If value is null, the method returns false

Answer 4

It's simply the type system of c# compared to languages like PHP, Perl, etc.

A condition only accepts Boolean values, null does not have the type Boolean so it doesn't work there.

As for the NULL example in C/C++ you mentioned in another comment it has to be said that neither C nor C++ have a boolean type (afair C++ usually has a typecast for bool that resolves to an int, but thats another matter) and they also have no null-references, only NULL(=> 0)-pointers.

Of course the compiler designers could implement an automatic conversion for any nullable type to boolean but that would cause other problems, i.e.:

Assuming that foo is not null:

if (foo)
{
  // do stuff
}

Which state of foo is true?
Always if it's not null?
But what if you want your type to be convertable to boolean (i.e. from your tri-state or quantum-logic class)?

That would mean you would have two different conversions to bool, the implicit and the explicit, which would both behave differently.

I don't even dare to imagine what should happen if you do

if (!!foo) // common pattern in C to normalize a value used as boolean,
           // in this case might be abused to create a boolean from an object
{
}

I think the forced (foo == null) is good since it also adds clarity to your code, it's easier to understand what you really check for.

Answer 5

"I think it's fairly reasonable to assume that null means false"

I don't agree. IMHO, more often than not, false means "no". Null means "I don't know"; i.e. completely indeterminate.

Answer 6

One thing that comes to mind what about in the instance of a data type, like int? Int's can't be null, so do they always evaluate to true? You could assume that int = 0 is false, but that starts to get really complicated, because 0 is a valid value (where maybe 0 should evaluate to true, because the progammer set it) and not just a default value.
There are a lot of edge cases where null isn't an option, or sometimes it's an option, and other times it's not.

They put in things like this to protect the programmer from making mistakes. It goes along the same line of why you can't do fall through in case statements.