Check out Soma's post about the Nullable<T> DCR we recently implemented...we referred to the project as nullbox internally. This one kept me up at night on a few occassions, but was a lot of fun. :) Huge risk, but based on lots of feedback it was the right thing to do. And the team executed perfectly, nailing our target dates at each step along the way.

I alluded to this work here and here. I was vague and avoided answering probing comments intentionally. Now I can answer them...so ask away!

The core of this change is that the IL box instruction has been modified to recognize Nullable<T>s. For non-Nullables, behavior remains the same; but upon seeing one, it inspects its HasValue property. If HasValue is true, box peeks inside the structure, extracts the T value, and boxes that instead; otherwise, box simply leaves behind a null reference. Obviously, unbox has also been changed to allow nulls to be unboxed back into Nullable<T> structures. This had a rippling effect in the CLR codebase and also required changes to late-bound semantics to mimic the static case.

The result is that given

int? x = null;
object y = x;

both expressions

x == null
y == null

evaluate to true. And furthermore, given

bool F<T>(T t) {
    return t == null;
}

the following expressions

F(x)
F(y)

also evaluate to true.

I intend to post a more detailed summary of the DCR over the coming week[s].