Proposal: explicit NotNullable<T> wrapper

[epa]

Sometimes you change a type from nullable to not-nullable. For example from int? to int. But any code that checks the value against null, or uses the ? conditional access operator or ?? defaulting operator, will no longer compile. You must change all those occurrences at the same time as tightening the type.

Sometimes it would be useful to make the change in two steps. I propose NotNullable<int> which is a trivial wrapper for the underlying type int. It supports HasValue which always returns false, and Value which always returns the value. Comparison against null, the ?? operator, and ?. conditional access work too. At the same time it can be implicitly converted to a plain int without problems. You could change the type to NotNullable<int> without altering any other code, but then go through and simplify out the null tests later (perhaps helped by your development environment or by a compiler warning). In a large codebase with many branches, breaking up a change like this helps avoid merge conflicts and programmers blocking each other.

Another motivation is for automatically generated wrapper classes. For example some tools generate a class definition from a table definition in an SQL database. When the database has the type int null it will generate Nullable<int> in C#, and when the database has int not null it generates just int. However, if the database is changed to add a not null constraint, most C# code using the wrapper class will no longer compile. On the SQL side, changing a column from null to not null keeps all select queries working, and is effectively making a stronger promise on the values of the column. But the generated wrapper code in C# cannot stay working with the more constrained type, even if it is giving read-only access.

By having NotNullable<T> available in the language, the wrapper code for an int not null would be NotNullable<int>. Any code written against the previous database schema that only provided an int null (wrapped as a Nullable<int>) would continue to build and work correctly, although as before, you could later go through it and remove the redundant null checks.

I have filed this as a language idea as I'm not sure whether the NotNullable class could be implemented in the standard library. If it could, and still perform as well as a plain unwrapped type, please recategorize this as a standard library request.

[HaloFour]

I think that's more an argument for allowing arbitrary types to support ?? and other such operators, that way you can correctly refactor directly to int without requiring this weird struct intermediary, or you could define your own weird struct intermediary.

[epa]

I think that's more an argument for allowing arbitrary types to support ?? and other such operators,

I'd be content with that, but it seems like a bigger change, whereas a NotNullable<T> class doesn't affect you unless you choose to use it. You'd have to give every type the .HasValue and .Value accessors too.

[ladeak]

Sometimes you change a type from nullable to not-nullable. For example from int? to int. But any code that checks the value against null, or uses the ? conditional access operator or ?? defaulting operator, will no longer compile.

Question 1

Not compiling is exactly my preferred preference given I know where to 'fix' or change the code - that does not work anymore.

Given

int? a = null;
Console.WriteLine(a ?? 1);

// and some other part of the code might do:
Console.WriteLine(a ?? 2);

As I understand switching to the suggested NotNullable the code would still compile but it would be a breaking change in the behavior, both console writes printing 0.

Question 2

I am not sure how this would help you in other parts of the application either. Given existing method parameters that gets a value from a source that changed from int? to int:

void MyMethod(int? p1) would still need to changed to void MyMethod(NotNullable<int> p1) so I am not sure how much effort it can actually save.

[epa]

Question 1. That would not compile as you cannot assign null to a variable of type NotNullable<int> (any more than you could to an int). But if your example code started with int? a = 5; then you could indeed tighten that to NotNullable<int> a = 5; and it would compile and run with the same sematics.

Question 2. Sorry, I omitted to make clear that NotNullable<int> can be implicitly converted or used in place of int?. Then existing code continues to work.

[ladeak]

That leads me to the same thought as @HaloFour , making ?? overloadable. Then you could add all the missing bits to an int with the .net 10 extension's feature.

[tannergooding]

This is not something we're interested in pursuing.

It is a binary break to change from T to Nullable<T> or to some theoretical NotNullable<T>, which would prevent its usage in many scenarios.

NotNullable<T> would also restrict the ability to perform many operations and break code in other contexts that does work on T or T?.

As for needing to fixup many places at the same time when you change a type like that, it really sounds like something that people intentionally desire and/or which could be solved via tooling (such as an analyzer).