A Proposal to Add Option Types for References to C# 7

Mads Torgersen, C# language program manager at Microsoft, has recently outlined a proposal for the introduction of option types for references in C# 7. Option types are meant as a means to make the language safer and reduce the occurrence of null reference exceptions, which, as Torgersen says, are rampant in C# since any reference type can reference a null value.

C# does already provide support for nullable value types, i.e. based on struct, but not for reference types, i.e., based on class. Due to the complexity of adding option types to an existing language as an afterthought, Torgersen’s approach does not aim to provide a “watertight” mechanism, rather a way to detect where code may dereference null and warn against it.

So, for an existing reference type T the new proposal would require the following:

• T is used to represent a non-nullable type;
• T? is used to represent a nullable reference type;
• the compiler emits a warning when:
  • a nullable T? type is dereferenced or converted to non-nullable type;
  • null/default(T) is assigned to non-nullable T type variables;
  • flow analysis has detected that a nullable reference is very likely not to be ever null;
  • constructors do not assign non-nullable references before returning;
  • a non-nullable reference is used in a constructor before assignment.

On the other hand, there is no way to ensure that a non-nullable array does not keep its null elements it is initialised with.

Using the null-conditional operator, ?. introduced with C# 6, the following would hold:

string s;
string? ns = SomeStringMaybe();

s = ns;                     // emits warning
if (ns != null) { s = ns; } // ok

WriteLine(ns.Length);       // emits warning
WriteLine(ns?.Length);      // ok

Altough such an approach has been devised so it does not break any existing code, it could potentially break compiler behavior, since in current C# T actually represent a nullable type. Therefore, says Torgersen, a mechanism shall additionally be provided to switch off warnings to ensure compatibility across C# versions and assemblies.

It is important to note that a non-nullable type T would be still allowed to contain null, mostly due to assembly compatibility considerations, only it would cause a warning when assigned null. This would also make C# 7s approach quite different to that of other languages, such as Swift option types and Haskell Maybe, where option types can be seen as sort of wrappers around their base types (actually, a generic in Swift’s case and a monad in Haskell’s).

The proposal as such has met mixed reactions, as voiced in the comments to the post. Some fear that by redefining the meaning of type T to be non-nullable, any existing C# codebase will produce a lot of warnings that will make them not useful at all. Others have expressed the idea that non-nullable type shall be represented by T! or otherways differentiated from the basic type T, which would remain nullable. This approach, though, would not benefit in any way existing codebases, which should be refactored to take benefit of non-nullability. Others still have embraced the idea and expressed the preference for a “strict” mode where nullable types are effectively wrapped through an option<T> or equivalent mechamism.