The Null Coalescing Operator (??)

One of the most useful yet little-known features to come out of C# 2.0

Introduction

I'm constantly surprised by the number of developers who aren't aware of this handy piece of syntax. It's my favourite thing to come out of C# 2.0 and no developer should be without it.

Like the conditional (?:) operator's big brother... introducing it for your coding pleasure...

The Null Coalescing Operator (??)

The null-coalescing-operator is a brilliant new terse operator that provides syntax for beautifully concise ifstatements. Essentially, it returns the left-hand-side of the ?? operator, unless null, in which case it executes and returns the right-hand-side of the operator. This may be a statement or a variable reference. Let's jump straight to some examples:

Here's an interesting example derived from an idea in the discussions below. It shows how an operator override can be used within an object's definition to enable shorthand syntax for double-null checking. The scenario is checking an object property for null using a null-coalescing-operator, but also defaulting when null-object-reference occurs; which would normally cause a runtime exception. (Note that I don't recommend actually using this approach, I just thought it made an interesting example.)

The Rules

To use the null-coalescing-operator, there are some compile-time ground rules.

The left-hand-side must evaluate to a reference or nullable type.

All evaluated statements must be of matching type, unless they can be implicitly converted.

Summary

As you can see from the examples above, this little gem is very powerful and the possibilities are endless. Of course the benefits are purely syntactical, but it helps keep the code clean and easier to follow. I hope you enjoy it as much as I do.

Comments and Discussions

...but is someone maintaining my code has to dive off to the language reference to fix a bug or add a feature I've failed as a developer

Depending upon your usages then I'd question if you have failed or whether they have - it's hardly difficult to comprehend the use of this operator, therefore I would say if they have to dive off to the language reference it is they that have failed to do their job.

If you had written something along the lines

a ?? b ?? c ?? d ?? e ?? "Hello World"

then yes, one could question your code but if it's something as simple as

Terse means to be very expressive with very little spoken. Assembler is not terse by any stretch; in fact, it's verbose. Probably the most meaningfully verbose language, by design.

As for what you actually meant to say, which is that adding vocabulary decreases legibility, I'd say this one is justified. The idea that zero/empty/nothing/unassigned can be expressed by anything more than null is bad enough; allowing the developer to address that ambiguity and unify the concept of "null" in an atomic expression allows for the code to be read more at its intended level of abstraction, thus keeping the reader's train of thought on track.

Furthermore, I don't think this particular operator is as much of a pedagogical challenge as, say, nullable types, which requires the reader to not only know the operator but also understand new concepts. You'll only ever have to look it up once in your life (which takes less than a minute thanks to modern technology ) to appreciate it.

It all comes down to readability of the source code. Does the terse operator make the code more or less readable?

A terse construct can improve readability by expressing a common concept in a distinctive, non-redundant way, that can be conceived with least cognitive load. It can also worsen readability, by encoding an uncommon, yet complex construct in a simplistic, non-intuitive way.

For the operator in question, ther next best alternative to value ?? default would be either the ternary operator, value != null ? value : default;, or restructuring the code into an if/else block. Both introduce more code points to understand, and have an redundant occurance of value.

Worse, I could write code that looks like thi pattern, but isn't - either intentionally, or as a mistake:object x = (Container.Matrix[i,j] != null) ? Container.Matrix[j,i] : Container.DefaultValue;

I don't think it's fair to compare assembler to this. Assembler has a completely different problem: the same idea can be expressed in many valid (and - depending on context preferrable) ways, e.g.
mov eax, [value]
or eax, eax
jz L1
mov eax, [default]
L1:

Although I use the ?? operator, thanks for this article. You gave me few new ideas which will help me in the future coding., like the foo ?? (foo = new List()); in a property getter or operator + to "access" a property of a null object. In such cases I used the "?:" statemnt.
By the way, it is debateble if creating an operator "
+" which would return Empty if an object is null is a good style coding (sometimes it is better to put a natural even if we are in the next bar*).

* - to code something explicitely, in this case to not force a potential reader to search for the operator's definition if it is so simple.

Greetings - Gajatko

Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.

I too was surprised when I discovered this operator that it was not more commonly used. It is quite handy. However a note to your readers: the expression on either side of the ?? must evaluate to the same type. This is the one limitation of this operator as it doesn't allow for an object to be manipulated within the comparison.

For example, if you have a complex object and need to access a particular property of that object, you can't just say something like:

address.StreetName ?? "n/a"

...if address is null. Nor will

address ?? "n/a" work because that doesn't allow you to get the street name. Not the best example, just though of it off the top of my head.

* * *

To clarify what I mean here, I would rather the operator work on the basis that if the LHS equates to null OR throws a null reference exception, then the RHS will be used. But that's just me.

It would be nice to have an operator that shortens "a != null ? a.B : null". It would be a lot more useful than ??.
Let's call it .?
Then your code would simply be ' address.?StreetName ?? "n/a" '. Shows address.StreetName if both address and address.StreetName at not null, otherwise it shows n/a.
For now, consider using the null object pattern if you find yourself writing "a != null ? a.B : null" (or the longer form using "if") a lot.

That's a neat idea, I quite like that. I'm always in favor of syntactical enhancements to make my job easier.

Tho I would order it '?.' so as to imply that the object being "questioned" is the address object, while the following ".StreetName" is only to be applied if the object is not null, whereas if the object is null, evaluation skips ahead to the RHS of the ?? operator:

Yes, '?.' looks better than '.?'. Though '?.' would be a single operator, as just 'address?' makes no sense. So 'address? ?? "n/a"' would be invalid syntax.
In my program there a few places where I need use "a?.b?.c?.d" - such nested accesses get horribly messy without the ?. operator, so I had to use the null object pattern. But I think patterns are just workarounds for missing language features.

Just playing with implicit operators. Obviously not as good as a framework implementation, but you could almost pull it off. Unfortunately it doesn't look possible to add a new ? operator, so had to use + instead.

Yeah I considered that too. Hardly ideal tho as it involves creating a new object which could potentially involve a lot of overhead. Not to mention it only works if the object has a default constructor AND initializes the fields to null.

This also allows the ability to capture with more detail several unknown conditions.
E.g.
1. The user has not yet specified the address
2. The user has no fixed address
3. The user does not know the address
...

For each of these it would be reasonable to replace Street.Empty with another static readonly field (Street.NotSpecified, Street.Unknown, Street.NoFixedAddress, ...). We can then use the Street.ToString() directly or easily compare to those static fields if there is specific logic needed in the application.
our code becomes even more descriptive now:

Address address = Address.NotSpecified

I don't like the op + on address in the article. Syntactically great - you save a bunch of characters; however, semantically the positive of an address doesn't mean anything and only adds to a maintenance programmer's pain in having to deal with your app.

Yes I like the idea of providing more information representing the state of an object instead of just "null" which could mean several things, as you've illustrated. I think what we were really getting at here is that it would be convenient to have a syntactic means of checking whether or not a particular object was "not null", or in other words if it had a proper value.

I also don't like using symbols like + arbitrarily to represent operations, however this is also partly the fault of Microsoft for not allowing much flexibility when it comes to operator overloading in C#. It would really be nice if we could define our own symbols and combinations of symbols to mean certain syntactic things--then we could define the '?.' operator ourselves, for instance.

That's right, I wasn't suggesting anyone use the (+) implementation from the example. I was seeing how close I could get to the imaginary null checking .? synatax we discussed in the thread eariler by messing with operators.

The JoshuaMcKinney example is much more the sort of code you might use in the real world, depending of course on the desired behaviour of the app.