Tag: Operators

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, `infoof`2 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 `INotifyPropertyChanged`5, 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.

var x = new MyClass();

ReturnTypeOfDoSomethingCool y = null;
if (x != null)
{
    y = x.DoSomethingCool();
}

// or, perhaps,

var y = x == null ?4;

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.

var x = new MyClass();
var y = x?.DoSomethingCool();

// and, with an indexer,

var a = new List<int>();
Console.WriteLine( a?[0] ?? "nothing" );

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?`5. 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`.

int? x = 10;
int y = x ?? 0;

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`:

int? x = 10;
int y = x?.Value;

Whereas this will work just fine:

int? x = 10;
string y = x?.ToString();

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. ReturnTypeOfDoSomethingCool)null) : x.DoSomethingCool();

    Or, if using an indexer:

    var x = new List<int>();
if (x != null)
{
   Console.WriteLine(x[0]);
}

Console.WriteLine(x == null ? "nothing" : x[0].ToString( [↩]
  5. also expressible as `Nullable<int>` [↩]