Proposal: Non-Nullable Reference Types and Generics

[jeffanders]

Non-Nullable Reference Types and Generics

The current proposal for nullable reference types in C# (#36) only briefly touches on generics and leaves a number of open questions. This proposal attempts to more fully consider how non-nullable reference types will work with generics. This proposal is only applicable to an assembly that has opted-in for non-nullable references.

Nullability

Every variable will be assigned a nullability. There are three possibilities:

1. Nullable
2. Preserving
3. Non-nullable

This forms a nullability hierarchy with regards to compiler enforcement of nullability gurantees from weakest to strongest.

Preserving can only apply to variables declared with a type of a generic type parameter as explained in detail later. All other variables are either nullable or non-nullable.

Value and reference types are non-nullable while Nullable<T> (e.g. int?) and reference types with the nullable modifier (e.g. object?) are nullable.

A variable may only be assigned a value that has an equal or stronger nullability (the assignment strength rule).

Generic Type Parameters

Generic type parameters subject to a struct (or equivalent) constraint are not affected by this proposal. For example

// the return value and t parameter are both non-nullable
T IdentityA(T t) where T: struct { return t; }
// the return value and t parameter are both nullable
T! IdentityB(T! t) where T: struct { return t; }

All other variables of type corresponding to a generic type parameter are preserving. Variables of a preserving type also follow the non-nullable rules within members for which the type parameter except for the assignment strength rule. This includes disallowing the use of the default operator. In all other members the type parameter will preserve the nullability of the type argument.

T IdentityC<T>(T t) { return t; }

string s1 = IdentityC("hello world"); // ok, T is inferred to be a non nullable string
string? s2 = null;
s2 = IdentityC(s2) // ok, T is inferred to be nullable
string s3 = IdentityC(s2) // error, T is inferred to be nullable

// TODO: move somewhere else 
U IdentityD<U>(U u) { return IdentityC(u); } // U is effectively nullable and therefore so is T within IdentityC
U! IdentityE<U>(U! u) { return IdentityC(u); } // u is annotated as non nullable and therefore T is effectively non nullable within IdentityC
U IdentityF<U!?>(U u) { return IdentityC(u); }!?> // U is effectively preserved and therefore so is T within IdentityC

Variables declared with the type of a generic type parameter not constrained to be a struct can now use the nullable modifier. For example:

T? IdentityD<T>(T? t) { return t; }

// all of the below is ok
int? i = IdentityD(0);
i = IdentityD(i);
string? s = IdentityD("hello");
s = IdentityD(s);

It is important to note that the nullable modifier is only encoded via an attribute and it therefore does not affect the runtime or assembly representation of T. i.e. string and string? are specialised to IdentityD<string> and int and int? to IdentityD<int> and IdentityD<int?> respectively at runtime.

Preserving type parameters also facilitate preserving the semantics of most existing generic code with the occasional addition of a nullable modifier (which will not impact consumers on C# compilers that don't understand non-nullable types)

For example FirstOrDefault can naively be implemented as follows:

T? FirstOrDefault<T>(this IEnumerable<T> e)
{
  foreach(T t in e)
    return t;
  return default(T?);
}

IEnumerator<T> would likely be updated so that the Current property would be T? as shown below since typical implementations would return default(T?) if MoveNext returned false or had never been called (but that behaviour is specifically undefined). Alternatively leave Current as T and implementations may need to cast T? to T inside Current (which is again already covered by the existing contract of undefined behaviour).

public interface IEnumerator<out T> : IDisposable, IEnumerator
{ 
  new T? Current { get; } 
}

If a preserving type parameter A is used as a constraint for another type parameter B then B must also be preserving (e.g. B may not be constrained to be a struct). Further it also constrains the permitted nullability of type argument B to be stronger than or equal to the nullability of type argument A. For example

A IdentityG<A,B>(B b) where B : A { return b; }

Animal a = IdentityG<Animal,Cat>(new Cat()); // ok
IdentityG<Animal,Cat?>(new Cat()); // error
IdentityG<Animal?,Cat>(new Cat()); // ok
IdentityG<Animal?,Cat?>(new Cat()); // ok
IdentityG<T,Cat>(new Cat()); // error T is only preserving
IdentityG<Cat, T>(new Cat()); // ok since Cat is non-nullable which is stronger then preserving T provided T is or inherits from Cat

When inferring the effective nullability of a preserved type parameter T for a method invocation where the type parameter is used with multiple parameters then the effective nullability will be the weakest effective nullability of the argument supplied for parameters of type T. For example consider the following method and invocations:

T Bar<T>(T x, T y) { ... }
Bar("hello","world"); // both arguments are non-nullable and therefore so is the return value
string? s = null;
Bar("goodbye",s); // s has the weaker nullability (nullable) and therefore the return value is nullable   

Other Considerations/Options

The approached presented here is forwards compatible with existing C# compilers or when non-nullable references have not been opted-in. However for the benefit of a non-nullable aware C# compiler a number of library changes would be necessary to include the nullable attribute against certain fields, parameters and return values for example (such as the FirstOrDefault<T> and IEnumerator<T>.Current examples above). This would require a new version of the BCL and other libraries which might not be possible. A mechanism might be required to allow a compile time only companion assembly for any assembly. This would be similar to TypeForwardedToAttribute but only for compile time and would only be for the purposes of constructing a union of applied attributes.

When overriding a virtual member that uses a preserving type parameter with the nullable modifier (i.e. T?) the signature must match the original virtual declaration as intervening overrides in other assemblies might have been compiled without knowledge of/support for non-nullable references.

This proposal disallows default(T) where T is a preserving type parameter and instead you must use default(T?). We could simply interpret the former as the latter which might simplify porting existing generic code where the use of the default operator may already be prevalent)

It is worth considering whether it is valuable for type parameters to be constrained to only be non-nullable. For example:

T IdentityA<T!>(T t) { return t; }
string s = IdentityA("hello"); // ok
string? s2 = null;
IdentityA(s2); // error s2 is nullable

The use cases over beyond what preserving type parameters provide seem minimal and it adds extra complications involving inheritance and overriding virtual members.

[jeffanders]

The above proposal is adapted from my previous non-nullable reference types proposal dotnet/roslyn#4443. However, that proposal was based on explicitly annotating declarations as not nullable via T! which the LDT has made fairly clear is not their preferred approach. Regardless I implemented a prototype of my original proposal that implemented between a quarter and a third of that proposal including preserving type parameters. That prototype is available in https://github.com/jeffanders/roslyn in the nonNullableReference branch if it is of interest to anyone.

[andrewmurphyio]

I really think @jeffanders approach is the best way to solve this issue.

It provides backwards compatibility (as null-ability is assumed by default and you opt in to non-nullable)

The only counter argument to it, as far as I can see, is the fact it differs to value types (which assume non-nullable by default, the opposite)

[HaloFour]

@andrewm1986

It provides backwards compatibility (as null-ability is assumed by default and you opt in to non-nullable)

The reason the team considered and rejected that approach is because non-nullability is, by far, the majority case. It would make considerably more sense to reduce the amount of adornment required to adopt this feature.