At last, C# is getting “?.”, sometimes called the Safe Navigation Operator

Visual Studio (and many other Microsoft Products) uses http://UserVoice.com as a feedback mechanism for users to suggest and vote on product features. One of the most popular features, with 3,752 votes, a new “?.” operator for the C# language, sometimes called the Safe Navigation Operator.

The news

Rejoice. Yesterday, Tuesday, February 25, 2014, on the Visual Studio User Voice, Mads Torgersen, the C# Language PM, responded on behalf of the Visual Studio Project Team. He said, “We are seriously considering this feature for C# and VB, and will be prototyping it in the coming months.”

The truth is, talk about this operator has been going on for a long time. Simplified syntax that favors readability and maintenance has been the name-of-the-game for each C# iteration. Your code does more and your syntax gets less and less. To their credit, C# is the most well thought-out, refined software language in existence – and it shows by its popularity and fandom.

Another inherent implication of Mad’s comment is the confirmation of the next version of C#. Of course, I think we all knew there would be another version of C#, but we can’t be certain until there’s something publically announced. Other conversations have occurred, this is just another. Long live CSharp.

What is it? Here’s the scenario

Consider getting the grandchild of a parent object like this:

var g1 = parent.child.child.child;

Okay, so, this is some poor coding because the value of child could be null. If I attempt to ask for the value of child and the containing object is null, a NullReferenceException will be raised and my app will crash.

Here’s what I mean. Consider this:

var g1 = [parent].[child].[null].child;

In this case, I was lucky enough to get two levels in before I hit a null object. But I did hit a null object, and as a result the runtime will thrown an exception.

Instead, you might add some error checking and do this:

// variation 1

var item = this.Parent;
item = (item == null) ? null : item.child;
item = (item == null) ? null : item.child;
var g1 = (parent == null) ? null : item.child;
if (g1 != null) // TODO

// variation 2

var g1 = (Child)null;
var item = this.Parent;
if (item != null)
{
    item = item.Child;
    if (item != null)
    {
        item = item.Child;
        if (item != null)
        {
            g1 = item.Child;
        }
    }
}
if (g1 != null) // TODO

Good. Now, this is safe and effective coding. The sample above shows two of many potential approaches. The first using the ternary operator in C#, the second using simple conditional blocks.  As we know, we cannot ask for a child property from an object that is null. So, we must check each level.

The conditional code is not difficult to write, but it certainly impacts the size of your code, the complexity of your code, and the readability of your code. Having said that, it’s what we all do today. Code like this shows up all the time and there is nothing wrong with that; but, what if there were a better way.

How the new operator workS

Consider getting the grandchild of a parent object like this:

var g1 = parent?.child?.child?.child;
if (g1 != null) // TODO

Wow! That’s the equivalent of testing every single level, but in a single line of code. The “?.” operator is basically saying, if the object to the left is not null, then fetch what is to the right, otherwise return null and halt the access chain.

It’s a wonderful addition to the language’s syntax.

Furthermore

Mad’s Visual Studio User Voice comment continued with a little more explanation of the operator’s implementation. He said, “If the type of e.x (etc) is a non-nullable value type S, then the type of e?.x is S?. Otherwise the type of e?.x is the same as that of e.×. If we can’t tell whether the type is a non-nullable value type (because it is a type parameter without sufficient constraints) we’ll probably give a compile-time error.” This comment, and the idea that a method call or indexer can be to the right of the operator are just candy.

> Now, let’s add NonNullable reference types and we’re really cooking.

Best of luck!