NRT - Provide switch to catch non-nullable refs from null-oblivious assemblies

[ewlloyd]

I propose the addition of a #nullable strict notation, or a compiler switch, or something similar, that tells the compiler to catch non-null-safe references to types declared or implemented in legacy null-oblivious assemblies. Perhaps a new, distinct compiler warning/error could be created to support this case: "Possible null reference to null-oblivious type".

From the discussion in #2205, there's a significant hole in the Nullable Reference Types implementation that allows references to objects of types implemented in null-oblivious assemblies to skate past compile-time nullability checks by not requiring the ? on such references.

One argument given is that there would be a mismatch between the null-oblivious notation T and the nullable-notated T? that might confuse newcomers to the language. I get that. I really do. That's why I'm recommending an opt-in strategy here, that allows those developers that want the extra safety to avail themselves as needed.

[saltukkos]

Right now our project using Resharper in pessimistic mode, so we have an ability to treat all 3rd library code as something that can produce null and we need either to annotate it with external annotations or write null checks after each method. But Resharper is very limited in nullable annotating and in flow-analysis, because it lacks nullability when passing delegates, using more of linq etc., also I'm only able to mark List<string> (with [ItemNotNull]), but not List<List<string>> (because there is no [ItemInItemNotNull] or something like [Nullable(1,1,1)] which compiler uses).
So we considered C#8 Nullability feature as the more powerful replacement for Resharper's nullability, but this non-configurable behaviour for Oblivious types ruins everything... We also need the ability to treat oblivious references as nullable

[ewlloyd]

Exactly -- the whole point of NRT was to provide native support for compile-time null-safety. As it stands, it's just not enough, given the massive base of null-oblivious code out there.

[keithyipkw]

One argument given is that there would be a mismatch between the null-oblivious notation T and the nullable-notated T? that might confuse newcomers to the language. I get that. I really do. That's why I'm recommending an opt-in strategy here, that allows those developers that want the extra safety to avail themselves as needed.

I suppose that you mean any IDE generated content. This should not be an issue if, for null-oblivious assemblies, either one of the followings is shown

1. T? instead of T
2. clear marks of null-oblivious

For out-dated documents on the Internet, users should be aware of null-obliviousness if they see any compiler warnings.