Clarify rationale for Nullable Reference Types breaking change

[Hounshell]

I'm curious if an alternate syntax has been explored, and if so the reasons for rejecting it. Specifically that would be using the "dammit" operator to specify that a type is non-nullable:

Foo a;   // This is a nullable Foo (for now)
Foo? b;  // This is a nullable Foo (forever)
Foo! c;  // This is a non-nullable Foo

This provides a backwards compatible forward path, with no surprises for developers not expecting this change. In the future the "for now" case could be migrated from the second case to the third.

This could also happen in the generics case:

List<T> d;   // This is a List of nullable or non-nullable objects (backwards compatible)
List<T?> e;  // This is a List of nullable objects
List<T!> e;  // This is a List of non-nullable objects; only non-nullable types are allowed.

This would lead to somewhat of an explosion of dammits (e.g. HashMap<String!, List<String!>!>!), but would provide some clarity and consistency in the intent. It should also reduce confusion where a type parameter is nullable and non-nullable.

At least addressing this in the proposal would be useful in answering this question before it comes up.

[iamcarbon]

I can imagine this being an opt-in feature that creates a wave of easily resolvable warnings. Don't think there'd be any breaking changes -- while providing an easy opportunity for a developer to harden their application against NullReferenceExceptions -- without changing syntax.

[MadsTorgersen]

Please take language feature discussion to the csharplang mailing list.

Thanks!

Mads

[gafter]

This is now the right place for language feature discussion.

[Joe4evr]

@Hounshell

I'm curious if an alternate syntax has been explored, and if so the reasons for rejecting it.

Yes. The original proposal way back on CodePlex was to keep un-annotated reference types nullable and use T! to declare that it's not null (it always gets initialized). However, considering that like >95% of the time, a developer intends for their variables/properties/fields to not be null, that would cause an explosion of using T! almost everywhere, making code a lot more noisy to read. In addition, T? is symmetrical with the syntax for nullable value types.

@iamcarbon

I can imagine this being an opt-in feature....

Did you even read the design document? 🙃

In summary, you need to be able to opt in/out of:

[Joe4evr]

Re: The design doc itself:

Certain patterns on generic types, such as FirstOrDefault or TryGet, have slightly weird behavior with non-nullable type arguments, because they explicitly yield default values in certain situations. We could try to nuance the type system to accommodate these better. For instance, we could allow ? on unconstrained type parameters, even though the type argument could already be nullable. I doubt that it is worth it, and it leads to weirdness related to interaction with nullable value types.

Why not have it so that methods returning open generic types like these are adorned with the attribute indicating that their return value can be null, but the compiler will just ignore the attribute if the type parameter is a non-nullable value type at the call-site? That seems to be the simplest solution, IMO.

void Foo(IEnumerable<int> ints, IEnumerable<string> strings)
{
    var i = ints.FirstOrDefault().GetHashCode(); //collection is of a value type, so no warning
    var s = strings.FirstOrDefault().GetHashCode(); //warning: 'FirstOrDefault()' would return 'null' if the collection was empty
}

[jcouv]

Here are the recent threads on the topic:

• Nullable strawman #790
• Nullable reference types: Mads's current thoughts #863

Backwards compatibility is a primary requirement for the feature.