Comparing structs to null [duplicate]

Answer 1

I believe when you overload an operator you are explicitly subscribing to the notion that you will handle all of the logic necessary with the specific operator. Hence it is your responsibility to handle null in the operator overload method, if it ever gets hit. In this case as I am sure you've probably noticed the overloaded methods never get hit if you compare to null.

Whats really interesting is that following Henks answer here, i checked out the following code in reflector.

Foo f1 = new Foo();
if(f1 == null)
{
  Console.WriteLine("impossible");
}

Console.ReadKey();

This is what reflector showed.

Foo f1 = new Foo();
Console.ReadKey();

Compiler cleans it up and hence the overloaded operator methods never even get called.

Answer 2

It looks like the issue is that when MS introduced nullable types, they made it so that every struct is implicitly convertable to its nullable type (foo?), so the code

if( f == null)

is equivalent to

if ( (Nullable<foo>)f == (Nullable<foo>)null) 

Since MSDN states that "any user-defined operators that exist for value types may also be used by nullable types", when you override operator==, you allow that implicit cast to compile, as you now have a user-defined == -- giving you the nullable overload for free.

An aside:

Seems like in your example, there is some compiler optimization The only thing that is emitted by the compiler that even hints there was a test is this IL:

ldc.i4.0
ldc.i4.0
ceq
stloc.1   //where there is an unused boolean local

Note that if you change main to

Foo f = new Foo();
object b = null;
if (f == b) { Console.WriteLine("?"); }

It no longer compiles. But if you box the struct:

Foo f = new Foo();
object b = null;
if ((object)f == b) { Console.WriteLine("?"); }

if compiles, emits IL, and runs as expected (the struct is never null);

Answer 3

I recomend you to take a look to those pages:

http://www.albahari.com/valuevsreftypes.aspx

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

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

Answer 4

This has nothing to do with serialization or COM - so it's worth removing that from the equation. For instance, here's a short but complete program which demonstrates the problem:

using System;

public struct Foo
{
    // These change the calling code's correctness
    public static bool operator ==(Foo f1, Foo f2) { return false; }
    public static bool operator !=(Foo f1, Foo f2) { return false; }

    // These aren't relevant, but the compiler will issue an
    // unrelated warning if they're missing
    public override bool Equals(object x) { return false; }
    public override int GetHashCode() { return 0; }
}

public class Test
{
    static void Main()
    {
        Foo f = new Foo();
        Console.WriteLine(f == null);
    }
}

I believe this compiles because there's an implicit conversion from the null literal to Nullable<Foo> and you can do this legally:

Foo f = new Foo();
Foo? g = null;
Console.WriteLine(f == g);

It's interesting that this only happens when == is overloaded - Marc Gravell has spotted this before. I don't know whether it's actually a compiler bug, or just something very subtle in the way that conversions, overloads etc are resolved.

In some cases (e.g. int, decimal) the compiler will warn you about the implicit conversion - but in others (e.g. Guid) it doesn't.

Answer 5

All I can think is that your overloading of the == operator gives the compiler a choice between:

public static bool operator ==(object o1, object o2)

and

public static bool operator ==(Foo f1, Foo f2)

and that with both to choose from it is able to cast the left to object and use the former. Certainly if you try to run something based on your code, it doesn't step into your operator overload. With no choice between operators, the compiler is clearly carrying out some further checking.

Answer 6

struct doesn't define the overloads "==" or "!=" which is why you got the original error. Once the overloads were added to your struct the comparision was legal (from a compiler prospective). As the creator of the operator overload is it your responsibility to handle this logic (obviously Microsoft missed this in this case).

Depending on your implementation of your struct (and what it represents) a comparison to null may be perfectly valid which is why this is possible.