Enforcing null-oblivious types at nullable boundaries?

[shawnnapora]

👋 My team has adopted nullable types, but we've been running into some issues when interacting with dependencies that have not yet also enabled nullable types. When interacting with those, we find that the libraries are null-oblivious, and our nullable checking fails since it doesn't warn about consuming null-oblivious into non-nullable types. Since we mentally expect in our nullable-enabled code to not run into that class of issues (since the compiler has been doing lots of nice checks for us), this is proving problematic and we're running into null refs in production code 🙀

I think in the ideal world, we'd be able to specify how we want certain libraries to behave when consuming them; that is, potentially have the compiler emit warnings when consuming oblivious types into non-nullable types for maximum safety.

How are other folks handling the "taint" of consuming null-oblivious types from libraries?

[RikkiGibson]

We hope that when we manage to ship #2145 that people will adopt it for parameters of public APIs when there's a possibility that their caller is null-oblivious.

[shawnnapora]

Thanks for the response! Reading through that, I think I might have the opposite problem: I'm a caller of a null-oblivious library and am inadvertently losing my null checking without realizing it.

[RikkiGibson]

Ahh, it looks like I got mixed up. Yeah, I think the question of consuming null oblivious libraries is tough. We don't plan on providing a "sidecar" mechanism to let people nullable-annotate a library's members from outside the library. Are you primarily running into this situation with third-party libraries that are not actively maintained?

One thing I think we could try to look at is to make symbol display behave differently on null-oblivious symbols when in a nullable-enabled context. For example, if you hover on the symbol string ThirdPartyLibrary.SomeType.SomeMethod() we could add an additional element to the symbol display, e.g. (null-oblivious) string ThirdPartyLibrary.SomeType.SomeMethod(), in the vein of (constant). So you could at least get the experience of "hey, we're not going to warn you, but exercise caution when calling this method".

I seem to recall that we weren't able to do this due to limitations with the Roslyn nullable public API. @jasonmalinowski @333fred in case you recall more specifically what the issue was or what we could be doing about it from the compiler/language side.

[333fred]

Improvements in this space are tracked by dotnet/roslyn#44063.

[shawnnapora]

Hi, thanks for that. I think the symbol display would be a good start, but I'm not positive that I would notice that. I think in my ideal world, I would have configurable compiler errors when consuming null-oblivious types unsafely. Obviously that's not desirable for everyone due to the huge amount of friction that it would add to getting to nullable, but it would be superb if I could have something like <Nullable>strict</Nullable> per-project or per-file with pragma.

I think one of the common things that I've seen in this space is a suggestion to write a Roslyn analyzer, but this doesn't seem straightforward to me and I'd want something a little more idiomatic and polished/supported out of the box. If there's some existing solution that folks use for that I'd be more than happy to kick the tires.