Is the C# compiler optimizing nullable types?

634 views Asked by At

Can anybody shed any light on why this unit test is failing in Visual Studio 2013?

[TestMethod]
public void Inconceivable()
{
    int? x = 0;
    Assert.AreEqual(typeof(int?), x.GetType());
}
1

There are 1 answers

0
Jaanus Varus On BEST ANSWER

Your test is failing because:

Calling GetType on a Nullable type causes a boxing operation to be performed when the type is implicitly converted to Object. Therefore GetType always returns a Type object that represents the underlying type, not the Nullable type.

You can read more from How to: Identify a Nullable Type.

Some examples taken from the previous article:

int? i = 5;
Type t = i.GetType();
Console.WriteLine(t.FullName); //"System.Int32"

Also note that:

The C# is operator also operates on a Nullable's underlying type. Therefore you cannot use is to determine whether a variable is a Nullable type. The following example shows that the is operator treats a Nullable<int> variable as an int.

int? i = 5;
if (i is int) { ... } // true   

You are correct in presuming that the C# compiler is optimizing nullable types. Here's a quote from Jon Skeet's C# in Depth which should answer your question:

It’s only with respect to boxing and unboxing that the CLR has any special behavior regarding nullable types. In fact, the behavior was only changed shortly before the release of .NET 2.0, as the result of community requests.

An instance of Nullable is boxed to either a null reference (if it doesn’t have a value) or a boxed value of T (if it does). It never boxes to a “boxed nullable int”—there’s no such type.


There's a similar thread on StackOverflow: Nullable type is not a nullable type?