Nullable<T> confusion

Question

Why is the following forbidden?

Nullable<Nullable<int>>

whereas

struct MyNullable <T>
{


}

MyNullable<Nullable<int>>

is NOT

Answer 1

I believe you can only use non-nullable value types in Nullables. Since Nullable itself is nullable, nesting this way is prohibited.

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

public Nullable(
    T value
)

Type: T A value type.

Answer 2

The generic type parameter for Nullable must itself be a non-nullable type (i.e. value type). This is the C# compiler warning I get, and it would seem to make sense. Tell me, why would you want to do such a thing anyway? I personally can see no use, and little meaning to such a declaration even.

Answer 3

Nullable allows you to take a value type and make it like a reference type, in the sense that the value either exists or not (is null). Since a reference type is already nullable it is not allowed.

Quoted from MSDN:

The Nullable(T) structure supports using only a value type as a nullable type because reference types are nullable by design.

Answer 4

This is because the struct constraint actually means 'not nullable' since Nullable, despite being a struct, is nullable (can accept the value null) the Nullable<int> is not a valid type parameter to the outer Nullable.

This is made explicit in the constraints documentation

where T: struct
The type argument must be a value type. Any value type except Nullable can be specified.
See Using Nullable Types (C# Programming Guide) for more information.

If you want the rationale for that you would need the actual language designer's comments on it which I can't find. However I would postulate that:

1. the compiler and platform changes required to achieve Nullable in it's current form are quite extensive (and were a relatively last minute addition to the 2.0 release).
2. They have several potentially confusing edge cases.

Allowing the equivalent of int?? would only confuse that since the language provides no way of distinguishing Nullable<Nullable<null>> and Nullable<null> nor any obvious solution to the following.

Nullable<Nullable<int>> x = null;
Nullable<int> y = null;
Console.WriteLine(x == null); // true
Console.WriteLine(y == null); // true
Console.WriteLine(x == y); // false or a compile time error!

Making that return true would be very complex and significant overhead on many operations involving the Nullable type.

Some types in the CLR are 'special', examples are strings and primitives in that the compiler and runtime know a lot about the implementation used by each other. Nullable is special in this way as well. Since it is already special cased in other areas special casing the where T : struct aspect is not such a big deal. The benefit of this is in dealing with structs in generic classes because none of them, apart from Nullable, can be compared against null. This means the jit can safely consider t == null to be false always.

Where languages are designed to allow two very different concepts to interact you tend to get weird, confusing or down right dangerous edge cases. As an example consider Nullable and the equality operators

int? x = null;
int? y = null;
Console.WriteLine(x == y); // true
Console.WriteLine(x >= y); // false!

By preventing Nullables when using struct generic constraint many nasty (and unclear) edge cases can be avoided.

As to the exact part of the specification that mandates this from section 25.7 (emphasis mine):

The value type constraint specifies that a type argument used for the type parameter must be a value type (§25.7.1). Any non-nullable struct type, enum type, or type parameter having the value type constraint satisfies this constraint. A type parameter having the value type constraint shall not also have the constructor-constraint. The System.Nullable type specifies the non-nullable value type constraint for T. Thus, recursively constructed types of the forms T?? and Nullable<Nullable<T>> are prohibited.

Answer 5

Nullable is special because there's explicit support for boxing and unboxing of Nullable types built into the CLR:

If you use the MSIL box instruction against a Nullable<T>, you will actually get a null as the result. There's no other value type which will produce a null when boxed.

There's similar and symmetrical support for unboxing.