Using Static Methods and 'Better Betterness' in C# 6

Erhan 8/29/2016 0
In this final installment of my series of articles covering new features in C# 6, I'll discuss two more new features in the C# 6 language: static using statements, and what is often called 'Better Betterness.' The first is new syntax that reduces code clutter by making extensive use of static methods. The second is a series of improvements to the language specification and compiler implementation that determines the best match for method overloads. Constructs that previously introduced ambiguities now can often resolve to a single method.Let's start with using static.

Static Methods

Suppose you had this line of code in your program:
var hypotenuse = Math.Sqrt(3 * 3   4 * 4);
It's easy to read on its own, but imagine it as part of a large class that provides a number of statistical analysis routines. In a quick scan of the code, you'd likely see the Math class name all over, cluttering up the code and making it hard to see the algorithms and other important details.The static using feature addresses this problem. We add this statement to the using statements in the source file:
using static System.Math;
Now we can remove the Math qualifier on any invocation of a method in the Math class:
var hypotenuse = Sqrt(3 * 3   4 * 4);
This feature went through a couple of iterations as C# 6 neared release. You may find resources on the Web stating that you don't need to include the static keyword as part of the using statement, but that information represented the earlier proposed syntax, and it has been changed. The final syntax makes it easier to determine which using statements represent using classes, and which statements represent using namespaces.Another change has made the feature more useful. The first proposal allowed you to add usingstatements only for static classes, which proved quite limiting. Some classes containing only static members had not been updated to include the static keyword (which was introduced in C# 2);System.Diagnostics.Trace is one example. It's marked sealed, but not static. However, there are no accessible constructors and no instance methods. Many other classes contain a large number of static methods and also support instances of that type. The string class is an example. Because strings are immutable, the class has many static methods that manipulate strings and return new objects. In some cases, adding a using static statement for System.String results in more readable code.That last sentence leads into my final point about the basic syntax: In a static using statement, you must specify the fully qualified name for any class you use. You can't simply type the class name, even if you already added a using statement for the enclosing namespace. For example, the following two statements won't compile; you must specify System.Math when you're using that class:
using System;
using static Math; // CS 0246. The type or namespace type could not be found.
You also can't use a C# keyword for types in which a keyword is defined as an alias for a type:
using static System.String; // this compiles
using static string; // this generates CS1001

Static Using and Extension Methods

The C# 6 language design team took care to make sure that introducing this feature wouldn't impact the resolution for extension methods. Remember that extension methods are static methods that can be called as though they're members of the type represented by the first parameter (or any type containing an implicit conversion from the type of the first argument to the type defined for the first parameter of the method declaration).The design goal was to make this addition to the language coexist with any code currently using extension methods. The rules governing using static and extension methods were written to ensure this goal. They may seem a bit involved, but that complexity is intentional.Consider this query:
using System.Linq; // So that the methods in the Enumerable class are found

var squares = from n in Enumerable.Range(0, 1000)
                let root = Math.Sqrt(n)
                where root == Math.Floor(root)
                select new { Number = n, Root = root };
The where query expression resolves to System.Linq.Enumerable.Where(). The select query expression resolves to System.Linq.Enumerable.Select(). Those methods are in scope because of the using statement shown above.I'd like to simplify the code by adding static usings so I don't have to type Math. and Enumerable. in the query above. I begin by modifying the using statements:
using static System.Linq.Enumerable;
using static System.Math;
Then I remove the name qualifiers in the query:
var squares = from n in Range(0, 1000)
                let root = Sqrt(n)
                where root == Floor(root)
                select new { Number = n, Root = root };
Notice that I could remove the using statement for the System.Linq namespace. Because I've imported all the methods in the System.Linq.Enumerable class via using static, Where andSelect can be found. However, because extension methods are designed to be called as if they were instance methods, using static won't bring those methods into scope to be called as static methods. Consider these two statements:
var sequence = Range(0, 1000);
var smallNumbers = Enumerable.Where(sequence, item => item < 10);
I can't remove the Enumerable class name from the second statement. I still have the using static System.Linq.Enumerable statement, but that won't add those method names to the global scope when they're called as static methods. I also have to include the using statement for System.Linq for this example to compile. Without it, I would have to write System.Linq.Enumerable.Where(...).The justification for this behavior is that extension methods are typically called as though they're instance methods. In the rare case where they're called as static methods, typically the reason is to resolve ambiguity. Therefore, it seems wise to force the developer to declare the class name.
CAUTIONThis decision introduces some potential ambiguity. Remember that the System.Linq namespace has two classes that implement the LINQ methods: Enumerable and Queryable. The methods in the Queryable class implement LINQ for query providers such as Entity Framework. The methods in the Enumerable class are used by LINQ to Objects, and they operate on collections in memory. Unless you want all of your queries to execute in memory, using LINQ to Objects, you must addusing statements for both System.Linq.Enumerable and System.Linq.Queryable:
using static System.Linq.Queryable;
using static System.Linq.Enumerable;
That addition will put both methods in scope, and the compiler's overload-resolution algorithm will correctly prefer the Queryable implementation over the Enumerable implementation.

Taking Advantage of 'Better Betterness'

The final feature we'll explore is often called "Better Betterness," though its official name is improved overload resolution. This feature is hard to demonstrate easily; in fact, it won't really affect your daily practices unless you look for it. In a number of areas, the compiler has improvements that enable it to pick one "best" method in C# 6, whereas in C# 5 and earlier those constructs resulted in an ambiguity. When you found such ambiguities, you would have needed to update the code to give the compiler better hints regarding the method you wanted the compiler to choose.The one I ran into most often was when I used a method group as the argument to a method. I expected that I could write this code:
// declared elsewhere:
static Task SomeWork() { return Task.FromResult(42); }

// Call it here:
but the compiler couldn't resolve the method correctly. I'd get an error saying, "The call is ambiguous between Task.Run(Action) and Task.Run(Func<Task>)," and I'd have to change the method group to a lambda expression so the compiler would find the better method (Task.Run(Func<Task>)):
Task.Run(() => SomeWork());
When code constructs you thought would work now do work in C# 6, thank "Better Betterness."

Initial Guidance on Static and 'Better Betterness'

I saved these two features for last in this series because, while they're important, they're the features that affect my daily coding practices the least. Improved overload resolution doesn't introduce any new syntax; it just removes rough edges around code that I previously thought should work. Now it does.By contrast, static using is a great feature, and I'm trying to make it part of my regular practices. But old habits are hard to break; I'm so accustomed to typing the class name before typing a static method that muscle memory just takes over. It's not such a significant improvement that I change existing code to take advantage of it.This wraps up my series on the new features in C# 6. Overall, it's an impressive update to my favorite programming language. As I write this, the release candidate is out, and I expect the final release to appear soon. I truly believe the whole C# community will be excited by this release. I'm becoming much more productive as I build habits using the new features. Get your hands on the bits, and start coding.