I'm using int as an example, but this applies to any value type in .Net
In .Net 1 the following would throw a compiler exception:
int i = SomeFunctionThatReturnsInt();
if( i == null ) //compiler exception here
Now (in .Net 2 or 3.5) that exception has gone.
I know why this is:
int? j = null; //nullable int
if( i == j ) //this shouldn't throw an exception
The problem is that because int? is nullable and int now has a implicit cast to int?. The syntax above is compiler magic. Really we're doing:
Nullable<int> j = null; //nullable int
//compiler is smart enough to do this
if( (Nullable<int>) i == j)
//and not this
if( i == (int) j)
So now, when we do i == null we get:
if( (Nullable<int>) i == null )
Given that C# is doing compiler logic to calculate this anyway why can't it be smart enough to not do it when dealing with absolute values like null?
I don't think this is a compiler problem per se; an integer value is never null, but the idea of equating them isn't invalid; it's a valid function that always returns false. And the compiler knows; the code
bool oneIsNull = 1 == null;
compiles, but gives a compiler warning: The result of the expression is always 'false' since a value of type 'int' is never equal to 'null' of type '<null>'.
So if you want the compiler error back, go to the project properties and turn on 'treat warnings as errors' for this error, and you'll start seeing them as build-breaking problems again.