C#6: The nameof Operator

Before discussing the nameof operator in C#6, I want us to consider why nameof exists at all. So, let's head back ten years to the heady days of 2005.

Wayne's World Flashback

When version 2.0 of the .NET framework arrived, it transitioned the fledgling platform from a sketch of what might be to a fully-formed platform that could support ongoing and future desktop and web development. Since then, each release of the framework and its associated languages have added a variety of bells and whistles that simplify and enhance the way we develop. Among many of the concepts and types introduced by .NET 2.0 was System.ComponentModel.INotifyPropertyChanged, part of the enhanced data binding introduced to Windows Forms development. This interface turned out to be a workhorse and introduced many developers to a new problem; making sure the string that named a variable matched the name of an actual variable.

Now, you may well object to this claim since various versions of ArgumentException already demanded this of developers, but I think we both know that until our tooling got smarter (like FxCop and Resharper), many of us just did not fill that argument out if we could help it. After all, the stack trace would tell us where the crash happened, we could put something meaningful in the exception message, and keeping that variable name up-to-date after refactoring was a pain. With the advent of INotifyPropertyChanged the benefit of putting the variable name in a string started to outweigh the costs. Quickly, patterns emerged to try and simplify this, from dubiously performant uses of reflection to build-time code generation. As tools matured, we could get refactorings that took these strings into account and warnings that could shout at us if a variable was mentioned that didn't exist. Few of these were particularly elegant or entirely foolproof, and none were both1. In addition to ArgumentException and INotifyPropertyChanged, property names would be used for logging and debugging.

In the Name of Progress

There were calls for a new operator to accompany typeof; the new operator, infoof2 would provide the corresponding reflection information of a particular code construct (like MethodInfo or PropertyInfo), simplifying not just obtaining the name of something, but also any reflection operation involving that something. All this use and discussion of meta-information did not go unnoticed. Eric Lippert blogged about infoof and why it would be useful, why it was so difficult to implement, and indirectly foreshadowed where we would be today. However, amid the discusson, there was little action.

In 2012, .NET 4.5 brought us the CallerMemberNameAttribute type and its siblings, CallerLineNumberAttribute and CallerFilePathAttribute. These new attributes enabled developers to decorate method arguments, indicating that the appropriate piece of information was to be injected into that argument when the method was called. This fell short of an infoof operator, but it greatly simplified use of INotifyPropertyChanged (and INotifyPropertyChanging, introduced in .NET 3.5). Alas, argument exceptions, logging, debugging, and other uses of method, variable, and property names were left as they were, often leading to mismatched error messages, obscure data binding bugs, and other problems.

That changed in 2015 with the new releases of both .NET and C#, and the new nameof operator in C#6. The nameof operator is sublimely simple; in fact, its concept seems so obvious that it's a wonder it took so long to appear3. Using nameof, we can inject the names of variables, types, methods, events, and properties into all sorts of places at compile-time4, knowing that if we change the name, our refactoring tools can update all references with confidence. Not only that, but our intent is clear; we want the name of this thing to be here and not just some string that happens to look like the name of some thing. While the nameof operator does not replace CallerMemberNameAttribute, which so deftly simplified INotifyPropertyChanged5, it does simplify other scenarios like throwing ArgumentException, logging errors, and outputting debug information.

In Conclusion

When I first contemplated writing a whole blog entry dedicated to nameof, I thought it was too simple a feature to warrant such focus; now I have finished, I believe nameof to be entirely worthy of the attention. Along with the fantastic string interpolation in C#6, I believe nameof is one of the simplest and most useful additions to the C#6 language. Like many C# and .NET features we now take for granted, nameof is a beautifully simple concept that we will come to rely upon. I believe it will save us countless hours of fixing erroneous refactoring, arguing over coding style and code reviews, and head-scratching at spurious errors.


  1. IMHO 

  2. pronounced, "Info Of" 

  3. As is often the case in software development, we were all too busy discussing the most complex use-case we could think of rather than the one that really needed solving 

  4. unlike reflection-based solutions that do all the work at run-time 

  5. nameof does provide an alternative, more wordy alternative for that scenario 

C#6: Null-conditional operators

With the release of Visual Studio 2015 in July came C# 6. Each iteration of C# has tended to have a theme and if there were a theme for this one, it would be developer productivity; all the new features in C# 6 appear to be either improvements to existing features, or syntactical shortcuts to simplify common operations. One of those syntactical shortcuts is the ?. operator1, which is accompanied by the similar ?[] operator2.

These new operators are collectively known as null-conditional operators. Most, if not all C# developers have used the null-coalescing operator, ?? and found it to be brilliant…until the next step was to call a method or property on the result. Though (something ?? somethingelse).Property seems like it might be a good idea, there is rarely a suitable somethingelse that doesn't just feel like hack, so invariably, we resort to an if or the conditional operator, ?:3.

Or, if using an indexer:

In C# 6, the ?. and ?[] operators step up to help. These new null-conditional operators check the value on the left of the operator and, if it is null, return null, short-circuiting the remainder of the expression; if the value on the left of the operator is non-null, the expression continues according to precedence rules.

Using these operators, we can express our earlier code much more succinctly and without resorting to convoluted, hacky ?? chains.

There isn't much else to write about these simple operators except to draw attention to how ?. works with Nullable<T> types such as int?4. Consider the ?? operator. When the ?? operator is applied to a nullable type like int?, it either returns the value wrapped in that int? or the value evaluated from the right of the operator. That is to say that instead of needing to reference the Value property of the nullable directly, the operator does that for you. The following assignment works because x.Value is returned from the ?? operator, not x.

The ?. operator works the same way, which means the following does not make sense and won't compile; Value is not a property of int:

Whereas this will work just fine:

In Conclusion…

The null-conditional operators, ?. and ?[] provide some shortcuts that will no doubt lead to clearer code, and I welcome their addition to the C# language. I hope that you do to.

 


  1. aka, the one-eyed Elvis operator 

  2. the robot Elvis, or Howard The Duck 

  3. The two-eyed Elvis 

  4. also expressible as Nullable<int>