Nullable<T> should satisfy unmanaged constraint iff T does

[tmat]

The following code should compile without error:

F(new Nullable<int>(1)); // error CS8377

void F<T>(T value) where T : unmanaged
{
}

Currently the compiler reports an error:

CS8377: The type 'int?' must be a non-nullable value type, along with all fields at any level of nesting,
in order to use it as parameter 'T' in the generic type or method 'Program.F<T>(T)'

Nullable<int> is clearly blittable. Moreover, if a type with exactly the same structure as Nullable<T> is defined with a different name, no error is reported:

F(new MyNullable<int>(1));

public struct MyNullable<T> where T : struct
{
    private readonly bool hasValue;
    internal T value;

    public MyNullable(T value)
    {
        this.value = value;
        hasValue = true;
    }
}

The following also compiles without error:

F(new S());

void F<T>(T value) where T : unmanaged
{
}

struct S
{
    int? a;
}

[tmat]

@RikkiGibson

[RikkiGibson]

It might be interesting to introduce the ability to be unmanaged iff the type argument meets an "imaginary" unmanaged constraint. One other place I would want this is on ValueTuple.

Once ref struct generics come around, it also seems useful for a container to be a ref struct iff the type argument is a ref struct, for example. Then, when the construction tells us it is not ref struct we get to put instances of it on the heap.

I think this area might be called "generic specialization" but I'm not deeply familiar enough to be sure.

[tmat]

Filed dotnet/runtime#81177 to track ILVerify reporting error if this was allowed by the compiler.

[ufcpp]

Not only unmanaged but also struct constraints:

static void m1<T>() where T : struct { }
static void m2<T>() where T : unmanaged { }

m1<int>();
m1<int?>(); // error CS8377
m1<(int?, int?)>(); // no error
m1<Wrap<int?>>(); // no error
m2<int>();
m2<int?>(); // error CS8377
m2<(int?, int?)>(); // no error
m2<Wrap<int?>>(); // no error

struct Wrap<T> { public T Value; }

[tmat]

Yes, it was pointed out by Jan on https://github.com/dotnet/runtime/issues/81177

[tmat]

Closing based on discussion in dotnet/runtime#81177

[TahirAhmadov]

I'm not very convinced by the reasoning in dotnet/runtime#81177. Specifically, if the requirement is to prevent Nullable<Nullable<int>>, why not use a static ctor which throws with such generic arguments?

[CyrusNajmabadi]

@TahirAhmadov Then please take it up with the runtime. We'll defer to Jan here when he says "It would be major breaking change with number of ripple effects.". If you disagree and can convince them otherwlse, then we can look at this again on the lang side.