InfoQ Homepage News Debate: Adding Non-nullable References to C#

# Debate: Adding Non-nullable References to C#

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.

## How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Adoption
Style

## 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.

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

## Community comments

• ##### It feels that we need a new language?

by Néstor Sánchez,

• ##### Re: It feels that we need a new language?

by Pierre-Luc Maheu,

• ##### Re: It feels that we need a new language?

by Néstor Sánchez,

• ##### Re: It feels that we need a new language?

by Pierre-Luc Maheu,

• ##### It feels that we need a new language?

Your message is awaiting moderation. Thank you for participating in the discussion.

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?

Your message is awaiting moderation. Thank you for participating in the discussion.

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?

Your message is awaiting moderation. Thank you for participating in the discussion.

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?

Your message is awaiting moderation. Thank you for participating in the discussion.

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

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

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.