Why don't Generic structs honour nullable reference types?

[Brondahl]

See dotnet/runtime#118517

interface IMyInterface<out T>
{
}

struct MyStruct<T> : IMyInterface<T>
{
}

class MyClass<T> : IMyInterface<T>
{
}


IMyInterface<object> a = new MyStruct<object?>(); // no warning
IMyInterface<object> b = new MyClass<object?>(); // warning CS8619

Particularly egregious when it happens to e.g. ImmutableArray<T?> and now my collection discards nullability-safety.

This seems like a straight-up bug, to me, but the response to my issue seems to think that this is "Works as Intended"!?

[BreyerW]

This is how i understand your situation:

object? in the context of struct is actually Nullable<object> thats completely normal object that can be fitted into object just fine hence no warning

However object? in the context of class is a purely syntactic sugar that drives nullability analyzer if im not mistaken hence the warning

And yes its working as intended cause when designing nullability enhancements it was done with understanding that it wont affect actual runtime in any way or form, meaning not every corner case will be covered 100% and Nullability<> is unfortunetly legacy but still kicking construct that could not be altered for back compat reason

Actually scratch that im not sure anymore but all i know for certain is that its working as intended cause when designing nullability enhancements it was done with understanding that it wont affect actual runtime in any way or form, meaning not every corner case will be covered 100%

[Brondahl]

If I raised an issue saying that List<string> noNulls = new List<string?>(); compiled ... you wouldn't seriously assert that this was working as intended, right?

[CyrusNajmabadi]

This is a compiler error, not a run-time issue?

Please file compiler error issues at dotnet/roslyn.

hits null-refs just as it would do if you disabled nullable types.
. you wouldn't seriously assert that this was working as intended, right?

it can depend. For example:

using System;
public class C {
    public void M() {
        string[] foo = new string[10];
        var v = foo[0].Length;
    }
}

No NRT warnings. But it will null ref at runtime. It is a non-goal for NRT to eliminate 100% of null refs. It's also a non-goal to avoid false positives.

But in the case you listed above, best is simply to have compiler team take a look.

[BreyerW]

I also don't see what this has to do with affecting the run-time?
This is a compiler error, not a run-time issue?

Thats exactly what i meant? What i said is that nullability feature was designed in a way that should not in any circumstance, way or form affect runtime meaning every error or warning (or lack of it in this case) is purely from compiler merely analyzing your code and that means it cant achieve perfect nullability and that was accepted by team as necessary evil to avoid having to touch runtime

This is a compiler error, not a run-time issue?

you mentioned a warning not an error thats important distinction and its important to check if u have 'warning as error' enabled

[Brondahl]

Ahh ... apologies; sounds like I've posted in the wrong place, and therefore assumed the wrong contexts/implied meanings.

Mea culpa

[Brondahl]

Raised here (for future readers/searchers): dotnet/roslyn#79845

[CyrusNajmabadi]

Please file an issue at Roslyn as compiler warnings are its domain.

[Brondahl]

Raised here (for future readers/searchers): dotnet/roslyn#79845

[Brondahl]

To check that I've understood the answers ...

I think that:

System.Console.WriteLine(typeof(List<string?>).IsAssignableTo(typeof(List<string>))); // outputs 'true'.

Is known and expected (at least, by the C# team 😅) - that the reftype nullability is entirely ignored by actual execution of code?

[Brondahl]

i.e. string? exists solely as a hint that the devs ask the compiler to check for them.

[colejohnson66]

Yes, reference nullability is completely ignored at runtime.

[BreyerW]

Yes precisely