Proposal: improvements to nullable reference types (VS 16.8, .NET 5)

[jcouv]

C# 8:

• [MaybeNull]T state tracking (proposal, done, C# 8)
• enforcing attributes in method bodies (done, C# 8)
• nullability attributes in OHI (done, C# 8)

Done for C# 9:

• dependent calls (MemberNotNull, done, gated on C# 9)
• T? with default constraint (done, gated on C# 9)
• record decision on side-effect of M(someMaybeNullValue); (done, issue Passing a value to a not nullable parameter should update state roslyn#43383)
• relax warning on return someBoolValue; (done, issue Relax enforcement of conditional attributes roslyn#44080)
• suppression in null-conditional (x?.y!.z, proposal Null propagation expression does not allow ! as a nested operator form (VS 16.8, .NET 5) #3393)

Considered for C# 9 (moved to follow-up issue for C# 10):

• Task<T> (LDM tentatively approved, needs design proposal for task-like types)
• LINQ (LDM expressed interested to handle Where, needs design proposal)
• uninitialized fields and constructors (no plan, aside from MemberNotNull)

LDM notes:

• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-12-18.md (discussion of var?, pure null checks)
• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-11-11.md ([MaybeNull] T)
• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-11-25.md (T??)

[erik-kallen]

Glad to hear that you are thinking about improving this feature, which has the chance to be one of the best things about C#.

However, I cannot see anything about member initialization (which is probably what is meant with the last point), without which I can't really see any use for nullable analysis in web applications, as pointed out in #2830

[qrli]

Isn't that the June 17 LDM #3589 favored explicit unconstraint over T???

[jcouv]

@qrli Thanks, updated to reflect recent decision

[mikernet]

Having T? mean MaybeNull is going to be incredibly confusing, with our without the unconstraint. What's wrong with allowing this syntax?

public async Task<[MaybeNull] T> M<T>()

That is infinitely clearer than what is proposed in the latest LDMs and aligns perfectly with how we annotate everything else as being maybe null.

[mikernet]

See here for details:

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-06-17.md#t

I can't believe anyone is looking at that syntax and thinking it is better than allowing the attribute to be applied to the type. Nullable annotations with generics are confusing enough, now I'm never going to be able to figure out at a glance if T? is nullable or maybe null.

[333fred]

The issue is that there's nowhere in metadata to put that. You can't add attributes to a particular usage of a type parameter. Additionally, just because you've gotten used to using attributes doesn't make them an actually good general solution. People ask about T? all the time because it's the natural first way to try to annotate something. It's literally the first question I asked when I started working on nullable.

[mikernet]

Put it in exactly the same place you would put it with public async Task<T?> M<T>() where T : unconstrained

[333fred]

Put it in exactly the same place you would put it with public async Task<T?> M<T>() where T : unconstrained

That's encoded as part of the NullableAttribute on a method, just like every other ? today. The presence of an attribute in syntax has specific meaning: it should be available in metadata. Why would you be able to put one attribute there, but not something like MaybeNullWhen or NotNull?