! operator for Nullable<T>.Value

[jods4]

I would like to pick up #1865 where it was left off.

Nullable reference types and value types are similar on the surface but very different internally.
#1865 asked what features of NRT could be ported to NVT.

I understand that the LDM ruled off the idea of automatically unwrapping a Nullable<T> to T based on dataflow analysis. That's sad but understandable.

In #1865 several people were supportive of introducting x! for value types as well, as syntax sugar for x.Value.

I would really like if that could happen:

• It's not a complex feature, x! is just sugar for x.Value if x is Nullable<T>
• It improves readability. When writing large expression involving several nullable variables, .Value is long, ugly, unrelated to the meaning of the code and readability suffers. Usability of nullables has greatly improved thanks to pattern matching, this is one of the last commonly used painful nullable syntax.
• It reduces the gap between NRT and NVT. On the surface they look really similar and recently a dev on my team just couldn't understand why price! was not working to grab the value of nullable decimal? price.

[HaloFour]

IMO there are two issues with this proposal as is:

1. This would change the meaning of existing code since you can already apply the null-suppression operator to value types, including Nullable<T>. One can argue that the current application of the operator in these cases is pathological, except perhaps in the case of generics.
2. This would cause the null-suppression operator to have an effect on the semantics of the code at runtime, which is something that operator was explicitly not supposed to do:

The null-forgiving operator has no effect at run time. It only affects the compiler's static flow analysis by changing the null state of the expression. At run time, expression x! evaluates to the result of the underlying expression x.

The first one probably bothers me more, although if people are already applying ! to NVTs assuming that they unwrap the value then perhaps it's a worthwhile break. But would they also expect a runtime error if the NVT is null?

[canton7]

I just tested it and I'm actually surprised C# lets you put a ! after a struct or a non-nullable reference type!
This usage makes no sense

For the case of a non-nullable reference type, note that nullability warnings are based on the nullable flow state of the variable, not on its declared type. For example:

public void M(string s)
{
    if (s != null) { }
    Console.WriteLine(s!.Length);
}

s is declared non-nullable, but its flow state gets turned into "maybe-null" by that null check, and so accessing s.Length raises CS8601 unless you add the !.

[jods4]

Interesting, didn't notice that before (probably because normally a non-null reference isn't supposed to be null but I can imagine exceptional situations).

I worked with NVT today again and I noticed that the dataflow also warns about possibly null NVT and you have to combine ! and .Value to satisfy the C# compiler.

This is not a great flow, but it also makes this proposal very impractical. I'm sure there are nvt!.Value in the wild and breaking this code is not desirable.

I feel like there's something to improve here, but I'm not sure how it can be done, so that the outcome is good but doesn't break existing code...

[Joe4evr]

(probably because normally a non-null reference isn't supposed to be null but I can imagine exceptional situations)

Upgrading existing code from null-oblivious to NRT-aware isn't really that exceptional, tho.

I feel like there's something to improve here

You can already either unwrap an NVT explicitly by using is { } v, or do the check against null/.HasValue and the compiler won't complain about dereferencing on .Value in the case where there is a value. What improvements could you possibly want?

[jods4]

In that context I knew the NVT wasn't null, so I don't want to include additional checks.

What improvements could you possibly want?

! feels redundant with .Value.
Value is an explicit unwrap knowing (or assuming) it's not null (or it'll throw). IMHO that's as explicit as ! itself.

I agree pattern matching improves handling NVT a lot.
Yet it's not always appropriate though, and when you need to manipulate several NVT in complex expression, I find the repeated .Value rather ugly and obscuring, I wish something like ! could be used instead (consistency, readability).

Recently I worked with more NVT than usual and I noticed other devs on my team were really struggling why ! "was needed here", yet "wasn't working??".

[canton7]

I'm fairly sure I've seen some other discussion around using ! as a synonym for .Value for NVTs, and my recollection (which might be wrong) was that it wasn't desirable, as ! strictly has no impact on the compiled executable, only on the warnings that the compiler produces.