Question

Why is the following forbidden?

Nullable<Nullable<int>> 

whereas

struct MyNullable <T> {   }  MyNullable<Nullable<int>>  

is NOT

Answer 1

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.