Remove null argument checks and thrown ArgumentNullExceptions

[bamarsha]

With C#'s nullable reference types feature enabled in all projects, checking if every argument is null and throwing ArgumentNullException is not as important. Null values can still appear even with non-nullable types, especially with public members or when interacting with code that doesn't have nullable references types enabled, but it's much less likely now. We have decided that the benefit of catching nulls at runtime that should already be checked by the compiler is not worth the cost of decreased code readability, so they're being removed.

[cgranade]

If the issue is one of code volume, would it be worth onboarding to .NET 5 and C# 9 at build-time, but using .NET Core 3.1 TFMs such as netcoreapp31 to get access to simplified null validation? That would require .NET 5 to be installed when building the compiler, but would not pass that requirement along to users.

[bamarsha]

I haven't heard about that proposal. To be honest, I think that proposal is the wrong approach - I'm not thrilled about the idea of putting !s on every parameter. If it was integrated with NRTs such that every non-nullable parameter automatically generated a check, then I think it would be a lot more useful.

Even with all of the ArgumentNullExceptions, I think we still had null-unsound code, for example in F# which strongly discourages null but can't prevent non-F# code, or F# code using types defined in non-F# code, from adding nulls. So even with the minimal null-checking proposal, we couldn't catch all null pointers. It makes sense to prevent as much as possible at compile-time, but I think there are too many places where null can be hiding at runtime to make checking worth it.

[cgranade]

I haven't heard about that proposal. To be honest, I think that proposal is the wrong approach - I'm not thrilled about the idea of putting !s on every parameter. If it was integrated with NRTs such that every non-nullable parameter automatically generated a check, then I think it would be a lot more useful.

Fair enough, I just thought I'd ask in light of that feature being on track for C# 9.

Even with all of the ArgumentNullExceptions, I think we still had null-unsound code, for example in F# which strongly discourages null but can't prevent non-F# code, or F# code using types defined in non-F# code, from adding nulls.

If I recall, support for C# 8's nullability metadata is a major focus for F# 5, so as to address that precise issue (https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1060-nullable-reference-types.md). Perhaps with your recent improvements to use <Nullable>enable</Nullable> throughout the C# parts of the compiler, it may be worth investigating if F# 5 can make good use of that metadata as well?

[bamarsha]

I could be wrong, but my understanding is that F# 5 will not include integration with C# nullable reference types, since the PR for that proposal is still open: dotnet/fsharp#6804. Maybe there is another PR that is in F# 5 that I'm not aware of though?

[cgranade]

Ah, got it; I think I'd seen it in early planning docs, but didn't realize it was deferred, sorry.

[ScottCarda-MS]

I've been wanting this for a while now. Thanks!