{"id":2122,"date":"2015-11-30T00:00:00","date_gmt":"2015-11-30T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/whats-new-in-c-6\/"},"modified":"2021-05-17T18:35:55","modified_gmt":"2021-05-17T18:35:55","slug":"whats-new-in-c-6","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/whats-new-in-c-6\/","title":{"rendered":"What’s New in C# 6"},"content":{"rendered":"
\n

Version 6 of the .NET C# programming language was introduced when Visual Studio 2015 was recently released. What were the most significant improvements in the language?<\/p>\n

The main focus of the release was the new compiler platform (known as ‘Roslyn’): There weren’t many obvious improvements or additions to the language as such, but the changes that I’ll mention in this article will definitely be appreciated by anyone who uses the C# programming language to develop applications.<\/p>\n

Improvements in Auto-Properties<\/h2>\n

C# has ‘auto-implemented properties’ (or, more concisely, ‘auto-properties’) that make property-declaration for simple properties more concise. Behind the scenes, a private, anonymous backing field is created that can be read or updated only via the property’s get<\/code> and set<\/code> accessors. They are declared with the get<\/code> and set<\/code> keyword followed by a semicolon.<\/p>\n

Initializers for Auto-Properties<\/h3>\n

It is now possible to declare the auto-properties just as you would a field:<\/p>\n

public class Person\r\n{\r\n    public string First { get; set; } = \"Jane\";\r\n    public string Last { get; set; } = \"Doe\";\r\n}\r\n<\/pre>\n
With this syntax, the initializer directly initializes the field that supports the property without actually using the set<\/code> accessor of the property.<\/p>\n
The property initializers are executed in the order they are declared, just as and along with field initializers. After all, they are, in fact, field initializers.<\/p>\n
As with the field initializers, property initializers cannot refer to this because like field initializers, they run before the object is properly initialized.<\/p>\n
The implementation of this new functionality is actually syntactic sugar, in that it generates code that is compatible with previous versions of the .NET platform. In fact, the code I’ve used to illustrate the new syntax is translated by the compiler to the following C# code 1:<\/p>\n
public class Person\r\n{\r\n    [CompilerGenerated]\r\n    [DebuggerBrowsable(DebuggerBrowsableState.Never)]\r\n    public string <First>k__BackingField = \"Jane\";\r\n    [CompilerGenerated]\r\n    [DebuggerBrowsable(DebuggerBrowsableState.Never)]\r\n    public string <Last>k__BackingField = \"Doe\";\r\n\r\n    public string First\r\n    {\r\n        [CompilerGenerated]\r\n        get { return <First>k__BackingField }\r\n        [CompilerGenerated]\r\n        set { <First>k__BackingField = value; }\r\n    }\r\n    public string Last\r\n    {\r\n        [CompilerGenerated]\r\n        get { return <Last>k__BackingField }\r\n        [CompilerGenerated]\r\n        set { <Last>k__BackingField = value; }\r\n    }\r\n}\r\n<\/pre>\n
Note that the <First>k__BackingField<\/code> and <Last>k__BackingField<\/code> have names that are not valid C# names. This is done to ensure that there is no chance of collision between a name that is given by the programmer and a name given by the compiler.<\/p>\n
Read-Only Auto-Properties<\/h3>\n
If you only declare a get<\/code> accessor, then the property is immutable everywhere except in its initializer and the constructor, so that it becomes read-only:<\/p>\n
public class Person\r\n{\r\n    public string First { get; } = \"Jane\";\r\n    public string Last { get; } = \"Doe\";\r\n}\r\n<\/pre>\n
In this case, the field is declared generated as readonly<\/code> (although this has importance only for the purpose of reflection).<\/p>\n
As in the previous case, the generated code will be:<\/p>\n
public class Person\r\n{\r\n    [CompilerGenerated]\r\n    [DebuggerBrowsable(DebuggerBrowsableState.Never)]\r\n    private readonly string <First>k__BackingField = \"Jane\";\r\n    [CompilerGenerated]\r\n    [DebuggerBrowsable(DebuggerBrowsableState.Never)]\r\n    private readonly string <Last>k__BackingField = \"Doe\";\r\n\r\n    public string First\r\n    {\r\n        [CompilerGenerated]\r\n        get { return <First>k__BackingField; }\r\n    }\r\n    public string Last\r\n    {\r\n        [CompilerGenerated]\r\n        get { return <Last>k__BackingField; }\r\n    }\r\n}\r\n<\/pre>\n
As with the read-only fields, you can also initialize a read-only auto-property in the constructor.<\/p>\n
public class Person\r\n{\r\n    \/\/ ...\r\n\r\n    public Person(string first, string last)\r\n    {\r\n        First = first;\r\n        Last = last;\r\n    }\r\n}\r\n<\/pre>\n
And, once again, the equivalent compiler generates code C# 1:<\/p>\n
public class Person\r\n{\r\n    \/\/ ...\r\n\r\n    public Person(string first, string last)\r\n    {\r\n        <First>k__BackingField = first;\r\n        <Last>k__BackingField = last;\r\n    }\r\n}\r\n<\/pre>\n
Expression Bodied Function Members<\/h2>\n
We can now use the same convenient fat arrow expression syntax (=><\/code>) to define lambda expressions to define function bodies.<\/p>\n
Expression Bodied Method-Like Members<\/h3>\n
We use the lambda fat arrow (=><\/code>) to define the body of methods as well as user-defined operators, type conversions and indexers. The expression to the right of the lambda arrow represents the body of the method.<\/p>\n
public Point Move(int dx, int dy) => new Point(x + dx, y + dy);\r\npublic static Complex operator +(Complex a, Complex b) => a.Add(b);\r\npublic static implicit operator string (Person p) => p.First + \" \" + p.Last;\r\n<\/pre>\n
The effect is exactly the same as if the methods have only a return statement. The above examples are translated by the compiler to:<\/p>\n
public Point Move(int dx, int dy)\r\n{\r\n    return new Point(x + dx, y + dy);\r\n}\r\npublic static Complex operator +(Complex a, Complex b)\r\n{\r\n    return a.Add(b);\r\n}\r\npublic static implicit operator string (Person p)\r\n{\r\n    return p.First + \" \" + p.Last;\r\n}\r\n<\/pre>\n
For methods whose return type is void<\/code> (or Task for asynchronous methods), the lambda arrow (=><\/code>) syntax still applies but the subsequent expression must be a statement (this is similar to what already happens with lambdas):<\/p>\n
public void Print() => Console.WriteLine(First + \" \" + Last);\r\n<\/pre>\n
…will be translated into…<\/p>\n
public void Print()\r\n{\r\n    Console.WriteLine(First + \" \" + Last);\r\n}\r\n<\/pre>\n
Expression Bodied Property-Like Function Members<\/h3>\n
Expression bodies can also be used to define the body of properties and an indexers:<\/p>\n
public string Name => First + \" \" + Last;\r\npublic Person this[long id] => store.LookupPerson(id);\r\n<\/pre>\n
Note the absence of the get<\/code> keyword, which instead is implied by the syntax of the expression.<\/p>\n
The previous examples are translated by the compiler to:<\/p>\n
public string Name\r\n{\r\n    get\r\n    {\r\n        return First + \" \" + Last;\r\n    }\r\n}\r\npublic Person this[long id]\r\n{\r\n    get\r\n    {\r\n        return store.LookupPerson(id);\r\n    }\r\n}\r\n<\/pre>\n
The ‘using static’ Directive<\/h2>\n
We can now import the static or enumerated members of a class into our namespace. We can then use the static members of a class directly without qualifying them with their namespace or type name!<\/p>\n
using static System.Console;\r\nusing static System.Math;\r\nusing static System.DayOfWeek;\r\nclass Program\r\n{\r\n    static void Main()\r\n    {\r\n        WriteLine(Sqrt(3 * 3 + 4 * 4));\r\n        WriteLine(Friday - Monday);\r\n    }\r\n}\r\n<\/pre>\n
The previous code is translated by the compiler to:<\/p>\n
class Program\r\n{\r\n    static void Main()\r\n    {\r\n        System.Console.WriteLine(System.Math.Sqrt(3 * 3 + 4 * 4));\r\n        System.Console.WriteLine(System.DayOfWeek.Friday - System.DayOfWeek.Monday);\r\n    }\r\n}\r\n<\/pre>\n
This feature is great when you have a set of related functions with a particular domain that is often used, such as System.Math<\/code>. We can reference the methods of the Math<\/code> class as though they were members of the class invoking them. It also allows you to specify the names of the members of an enumerated class as members of System.DayOfWeek<\/code> in the example above.<\/p>\n
Extension Methods<\/h3>\n
Extension methods are invoked like regular static methods, (See: https:\/\/msdn.microsoft.com\/en-gb\/magazine\/dn879355.aspx<\/a>) but they are called as if they were instance methods on the extended type. Instead of bringing these methods to the current scope, the static import functionality makes these methods available as extension methods without the need to import all extension methods in a namespace like before:<\/p>\n
using static System.Linq.Enumerable; \/\/ The type, not the namespace\r\nclass Program\r\n{\r\n    static void Main()\r\n    {\r\n        var range = Range(5, 17);                \/\/ Ok: not extension\r\n        var odd = Where(range, i => i % 2 == 1); \/\/ Error, not in scope\r\n        var even = range.Where(i => i % 2 == 0); \/\/ Ok\r\n    }\r\n}\r\n<\/pre>\n
This means that it will now be a breaking change to change a normal static method into an extension method, which was not the case before. Extension methods are usually only invoked as static methods when there’s an ambiguity. And, in those cases, it seems legit to require full qualification anyway.<\/p>\n
Null-Conditional Operator<\/h2>\n
It is often necessary to scatter null checks around code. Operators with null checks allow access to members and elements only when the receiver is not null, otherwise returning a null result:<\/p>\n
int? length = people?.Length; \/\/ null if people is null\r\nPerson first = people?[0];    \/\/ null if people is null \r\n<\/pre>\n
The above code is translated into:<\/p>\n
int? nullable = (people != null) ? new int?(people.Length) : null;\r\nPerson person = (people != null) ? people[0] : null;\r\n<\/pre>\n
The null-conditional operators can be very convenient when used with the coalesce operator (??)<\/code>:<\/p>\n
int length = people?.Length ?? 0; \/\/ 0 se people \u00e9 null\r\n<\/pre>\n
The null-conditional operators have a short-circuit behaviour. In the chain of access to members, elements or invocations immediately adjacent will only run if the original recipient is not null:<\/p>\n
int? first = people?[0].Orders.Count();\r\n<\/pre>\n
This example is, in essence, equivalent to:<\/p>\n
int? first = (people != null) ? people[0].Orders.Count() : (int?)null;\r\n<\/pre>\n
…except that people<\/code> is evaluated only once. None of the access to members or elements and invocations that follow the ? operator will run if the value of people<\/code> is null.<\/p>\n
Nothing prevents null-conditional operators from being chained, if null verification is required more than once in the chain:<\/p>\n
int? first = people?[0]?.Orders.Count();\r\n<\/pre>\n
In an invocation, a list of arguments in parentheses cannot be immediately preceded by the ‘?<\/code>‘ operator – It would lead to too many ambiguities. Therefore, the invoking of a delegate that one might expect if it is not null is not allowed. However, the delegate can always be invoked via its Invoke<\/code> method:<\/p>\n
if (predicate?.Invoke(e) ?? false) { ... }\r\n<\/pre>\n
A common use of this feature is the event trigger:<\/p>\n
PropertyChanged?.Invoke(this, args);\r\n<\/pre>\n
…which is translated to…<\/p>\n
var handler = PropertyChanged;\r\nif (handler != null)\r\n{\r\n    handler.Invoke(this, args);\r\n}\r\n<\/pre>\n
This is a thread-safe way to see if the event has subscribers, because it only evaluates the left side of the invocation once, and keeps its value in a temporary variable. Without this feature, you used to have to write to this pattern yourself.<\/p>\n
String Interpolation<\/h2>\n
The String.Format<\/code> method, and other similar methods, is very versatile and useful, but its use is a bit awkward and error-prone due to numerical markers ({0}<\/code>) that must match the position of the arguments supplied separately:<\/p>\n
var s = string.Format(\"{0} is {1} year{{s}} old.\", p.Name, p.Age);\r\n<\/pre>\n
The interpolation syntax allows strings to directly replace the literal string indexes by “holes” with the expressions that correspond to the values:<\/p>\n
var s = $\"{p.Name} is {p.Age} year{{s}} old.\";\r\n<\/pre>\n
As with the String.format<\/code> method, it is possible to specify shapes and alignments:<\/p>\n
var s = $\"{p.Name,20} is {p.Age:D3} year{{s}} old.\";\r\n<\/pre>\n
The content of the holes can be any expression, including strings:<\/p>\n
var s = $\"{p.Name} is {p.Age} year{(p.Age == 1 ? \"\" : \"s\")} old.\";\r\n<\/pre>\n
Note that the conditional expression is in brackets, so that: “s” is not confused with the format specifier.<\/p>\n
Formattable Strings<\/h3>\n
When not otherwise specified, a formatting provider uses the current culture of the current thread when invoking the String.Format<\/code> method, but this is not always what is wanted. That is why, as happens with lambda expressions, the compiler translates the interpolated string differently depending on the type of receptor expression.<\/p>\n
If the receiver of expression is the IFormattable<\/code> type…<\/p>\n
IFormattable christmas = $\"{new DateTime(2015, 12, 25):f}\";\r\n<\/pre>\n
…the compiler generates the following code:<\/p>\n
IFormattable christmas = FormattableStringFactory.Create(\"{0:f}\", new DateTime(2015, 12, 25));\r\n<\/pre>\n
This can be used as follows:<\/p>\n
var christamasText = christmas.ToString(null, new CultureInfo(\"pt-PT\"));\r\n<\/pre>\n
FormattableString<\/code><\/h4>\n
The concrete type returned by FormattableStringFactory.Create<\/code> is derived from:<\/p>\n
namespace System\r\n{\r\n    public abstract class FormattableString : IFormattable\r\n    {\r\n        protected FormattableString();\r\n        public abstract int ArgumentCount { get; }\r\n        public abstract string Format { get; }\r\n        public static string Invariant(FormattableString formattable);\r\n        public abstract object GetArgument(int index);\r\n        public abstract object[] GetArguments();\r\n        public override string ToString();\r\n        public abstract string ToString(IFormatProvider formatProvider);\r\n    }\r\n}\r\n<\/pre>\n
This provides access not only the format but also to the format string arguments.<\/p>\n
Backward Compatibility<\/h4>\n
The features introduced by the C# 6 are compatible with the previous .NET platforms. However, this particular feature requires System.Runtime.CompilerServices.FormattableStringFactory<\/code> and System.FormattableString<\/code> types that have been introduced only in version 4.6 of the platform. The good news is that the compiler is not tied to the location of these types in a particular assembly and, if we are to use this functionality in an earlier version of the platform, we just need to add the implementation of these types.<\/p>\n
‘nameof’ Expressions<\/h2>\n
Occasionally it is necessary to provide a string with the name of some program elements.<\/p>\n