Debate: Adding Non-nullable References to C#

| by Pierre-Luc Maheu Follow 4 Followers on Sep 28, 2015. Estimated reading time: 3 minutes |

The recent proposal to add non-nullable references to C# by Microsoft’s Mads Togersen sparked quite a debate in the .NET community. The reactions were diverse, ranging from praise to preferring status quo.

On Reddit, the proposal elicits many questions about backward compatility. Strilanc feels the proposal wouldn’t allow a smooth transition when turning the flag on:

This proposal needs more work. There's not nearly enough consideration for preserving binary compatibility, source compatibility, and for allowing a gradual transition of existing code.

1. It has an assembly-level switch that changes the meaning of every reference type name to be non-nullable. It changes the meaning of projected-sized chunks of code all at once, requiring massive upfront cost and risk. That is very very bad.

2. The generics part of the proposal needs more fleshing out. The fact that default(T) is no longer allowed in a lot of generic code is not explored at all. How does this issue affect existing code under this proposal, and how is it worked around? How do classes that need it opt into using default(T)?

3. It just lets arrays contain bad initial values? What is the point of putting it in the type system if you're just going to let it be blatantly violated?!

Backward compatibility towards external libraries is also a concern, as Maplemario writes:

But here's the problem. Say I'm using an old library where everything returns T regardless of nullability. Now, the paradigm shift is into assuming that T means non-null T, but I use a function which (validly, when it was written) returns null. Say it's in a rarely tested case of my program. In a perfect world, the documentation outlines this and I read the documentation so I know to null-check, or I remember that it's old code and null-check anyway. In the real world, there's no longer an imperative on me to do null-checking because "T means non-null T", and suddenly my program crashes because I'm dereferencing a null pointer.

Alternatives to the proposal are also actively discussed. A new notation for expressing non-nullability would be preferred by 00Davo:

As much as I'd like the bare type T to invariably be non-nullable for any reference, so only T? can ever hold null, it would be a nightmare for backwards compatibility. It'd be a lot less fragile to introduce a new, explicitly non-nullable reference notation - T! perhaps?

For others, implementing the proposal would be too problematic. Number127 suggests static analysis as an alternate approach:

Sadly, there are too many compatibility issues to introduce non-nullable reference types in a graceful way at this point. I think the most promising approach is static analysis to see what guarantees can be made about a reference while maintaining the current type system.

Static analysis is also discussed on GitHub. Paulo Morgado goes further, stating the current proposal is already disguised static analysis:

If I understand it correctly, this is nothing more than a method contract on steroids. There are no guarantees made by the compiler and less by the runtime. The compiler just does dataflow analysis on variables declared to be nullable.

On another topic, Tomas Petricek points out that other CLR languages like F# have to be considered in the proposal:

Can the proposal be clarified on how are the nullability annotations going to be stored at the CLR level? (I suppose these have no runtime meaning and they would just produce a .NET attribute or some other sort of metadata?)

It would be nice if some future version of the F# compiler could read and understand these and offer some sort of "strict" mode where nullable types are automatically exposed as option<'T> (or something along those lines).

The debate on non-nullable references isn’t new, as the question arose several times in the past years. As former Microsoft’s principal developer Eric Lippert states, retrofitting non-nullable references in a 15 years old language is a huge undertaking.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

It feels that we need a new language? by Néstor Sánchez

I hate to say this, because I love C#, but it clearly suffers from a heavy legacy "backpack", just because it was created to be "familiar" with other languages like Java or C++. I would like to see a new C# (let's say C##) having...
- Default non-nullable references.
- Type inference everywhere (including props/field declarations and lambdas), not just for local variables.
- Immutability with short syntax.
- Get rid of array covariance.
- Real Tuples
- Support for high order functions (with variable "arity" like in haskell)
- Metaprogramming (such as to make INPC easier to write)
In summary, be the best hybrid language between OO and functional programming.

Re: It feels that we need a new language? by Pierre-Luc Maheu

C# definitely carries some relic of the past with it. Being close to C syntax was pretty much mandatory for widespread adoption back at the time.

Looking at your feature list, it sounds like there's already a CRL language that meets most criterions. How about F#?

Re: It feels that we need a new language? by Néstor Sánchez

I prefer the C# focus, primarily OO with functional programming as alternative/second paradigm, instead of the opposite (the F# way). Plus, I really don't feel comfortable treating all as 'immutable' and doing "ingenious" tricks to simulate state changes.

Re: It feels that we need a new language? by Pierre-Luc Maheu

So a C# reboot, including what we learned in the last 15 years and with a stronger functionnal programming support. Interesting.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you