Keyword for non-nullalble type inference

[davidalamb]

When nullable reference types are enabled, you can declare objects using the var keyword, but that will always infer a nullable object, even if you explicitly instantiate it. E.g., var customObj = new CustomObj(); results in customObj being a CustomObj? instead of a CustomObj, due to use of var.

I propose a new keyword -- ivar -- to be used in place of var, and which would always result in a non-nullable instance -- in this case, a CustomObj. If the expression were to itself be null, the attempt to assign that expression result would itself throw a NullReferenceException.

[HaloFour]

The type of the variable isn't that important. The nullability state of the variable depends on the nullability of the expression used to initialize the variable and is tracked through flow analysis. The only time the nullability of the inferred variable type would even matter is if you reassigned it. There would be no warning on assigning a nullable value to the variable even if the previous value was non-nullable. However, flow analysis still takes place and an attempt at dereferencing the variable will issue a warning if you do not check for nullability.

Importantly, nullable reference types never affects the behavior of the code. That is very intentional, so that you can switch NRTs on and off without any impact to the behavior of the code. Rather than ivar I would suggest an extension method that could be used to guard against the value, or an unwrapping operator: #6034

[davidalamb]

an attempt at dereferencing the variable will issue a warning if you do not check for nullability

I don't want a thousand warnings from these sorts of things, and I dislike reading code littered with ! all over the place. It's a giant smell that distracts from the handful of places where it's been added by necessity. I want this settled at compile-time, with a big scary red error, and without having to worry about my colleagues misunderstanding the nullability restrictions at play.

[HaloFour]

This is settled at compile time, with a warning that can be set to an error through project properties. There's no reason to use ! in these cases.

[davidalamb]

I find it interesting that you highlighted Kotlin's val syntax. That's exactly the feature that I want, and is the keyword that inspired this idea. Obviously we can't add val as a new keyword at this point, given how much it would interfere with people's existing codebase (not to mention the confusion with regard to value types vs reference types). I only suggest ivar (short for instance var) because the number of collisions with existing code is likely low.

I just, basically, want a keyword that's a catch-all, like var, but I don't want warnings, and I don't want ! because it's ugly, distracting, and a code-smell, but the IDEs just getting rid of the warnings IMO is not a proper solution, because the variable is nullable.

[HaloFour]

I find it interesting that you highlighted Kotlin's val syntax. That's exactly the feature that I want, and is the keyword that inspired this idea.

Kotlin's val syntax has nothing to do with nullability, it has to do with mutability. Kotlin uses the !! postfix operator to forcibly unwrap a nullable value and throw at runtime.

I just, basically, want a keyword that's a catch-all, like var, but I don't want warnings, and I don't want ! because it's ugly, distracting, and a code-smell, but the IDEs just getting rid of the warnings IMO is not a proper solution, because the variable is nullable.

As mentioned, you can set those warnings to errors, and achieve this goal today with zero language changes. There's no reason to add another keyword to the mix which adds no additional benefits.

[HaloFour]

I honestly just think that the IDE and other tools should stop showing the variable type as nullable. That by itself would alleviate the majority of the confusion.

[antont]

Yep. I'm starting to use nullable in our project now, and am about to convert all uses of var to explicit type declarations, because it's so confusing to see the ? added to the type always otherwise in VS Code.