What's the purpose of the "where T : notnull" constraint for structs?

[DavidArno]

Consider the following piece of code from Sharplab:

public readonly struct S<T> where T : notnull 
{
    private readonly T _field;
    public S(T value) => _field = value;
    
    public T GetField() => _field;
}

static class C
{
    static void Main()
    {
        var x = default(S<string>);
        x.GetField().Inspect();
    }
}

As can be seen from the link, despite me marking the struct as T not being able to be null, it gives me no warning on default(S<string>) and I end up with _field (of type T) being null. Therefore there seems no point in using where T : notnull with structs.

Am I missing something?

[YairHalberstadt]

@DavidArno

I thinking you've overcomplicated the example:

public struct S
{
    public string Field { get; }
    public S(string field) => Field = field;
}

NRTs don't work very well with fields of structs, since you can default up a struct.

[DavidArno]

I guess it'll just have to remain an oddity until (if ever) we get non-zero default structs.

[YairHalberstadt]

See #2328 for a potential solution

[benaadams]

non-zero default structs.

Still has a problem with arrays as their elements are set to default

public struct S
{
    public string Field { get; }
    public S(string field) => Field = field;
}

static class C
{
    static void Main()
    {
        var x = new S[10];
        x[0].Field.Inspect(); // prints null
    }
}

[DavidArno]

@benaadams,

I agree. Any solution to non-zero default structs has to be a Core CLR change as default(S), and thus things like array elements etc must guarantee a non-zero initialised struct every time.

Anything else is just kicking the can down the road.