Auto Property Enhancements in C# 6
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Added in C# 3, automatic properties introduced a more concise syntax for a common idiom: Creating a public read/write property with a private backing field. This idiom is used in data-transfer objects, data-binding scenarios, and other common designs:
class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime DateOfBirth { get; set; }
}
From the first introduction of auto properties, C# developers have been asking for enhancements to this syntax that would support read-only properties, or immutable types. In the interim, the compromise would be to create a type in which the auto property's setters were private:
class Person
{
public string FirstName { get; private set; }
public string LastName { get; private set; }
public DateTime DateOfBirth { get; private set; }
public Person(string first, string last, DateTime birth)
{
this.FirstName = first;
this.LastName = last;
this.DateOfBirth = birth;
}
}
This compromise is close, but it doesn't accurately express the design intent. The syntax can ensure that only code inside the Person class can change the values of these properties, but it can't ensure that the values don't change once the Person object has been created. That goal required reverting back to the more verbose syntax of declaring the backing field explicitly as a read-only field and initializing it in the constructor:
class Person
{
public string FirstName { get { return firstName; } }
private readonly string firstName;
public string LastName { get { return lastName; } }
private readonly string lastName;
public DateTime DateOfBirth { get { return dateOfBirth; } }
private readonly DateTime dateOfBirth;
public Person(string first, string last, DateTime birth)
{
this.firstName = first;
this.lastName = last;
this.dateOfBirth = birth;
}
}
Compare this third version with the first. The class has now more than tripled in size, with no additional functionality. We expect better from a modern programming language.
C# 6 Brings Welcome Enhancements
C# 6 brings a much more concise syntax for read-only properties. Simply omit the set entirely:
class Person
{
public string FirstName { get; }
public string LastName { get; }
public DateTime DateOfBirth { get; }
public Person(string first, string last, DateTime birth)
{
this.FirstName = first;
this.LastName = last;
this.DateOfBirth = birth;
}
}
This syntax instructs the compiler to create a private backing field and a public getter. The backing field can be set through the property name, but only in a constructor. If you have a more complex model, any or all of the constructors can set the property. However, no other method, public or private, can modify the property or the backing field. In fact, you can't even access the backing field by name anywhere in your code.
This language enhancement enables you to create read-only properties that leverage the auto property syntax, making them much more useful in scenarios where the design calls for immutable types. The syntax is very concise and provides better support for your design.
There are other additions as well. You can add an initializer to an auto property, just like you can with any field declaration in your class:
public class Example
{
public int TheAnswer { get; set; } = 42;
}
The code above initializes the TheAnswer property of an instance of an Example to 42 (instead of the default int value of 0). Note that TheAnswer is a read/write property. You can apply initializers to read-only fields. This technique can be used in scenarios where you initialize a read-only instance field based on a static field:
class Person
{
private static int id = 0;
public int Id { get; } = id++;
public string FirstName { get; }
public string LastName { get; }
public DateTime DateOfBirth { get; }
public Person(string first, string last, DateTime birth)
{
this.FirstName = first;
this.LastName = last;
this.DateOfBirth = birth;
}
}
Some Initial Guidance on Auto Property Enhancements
As with expression bodied members, the new auto property features are syntactic sugar; you can create all the designs I've shown using features already in the language. However, these new features do enable you to create those designs in a much more readable and concise fashion.
I have quickly adopted the new syntax in any project that uses C# 6. It's become so natural that I miss these features when I'm working on a project that has not yet been updated to use the new compiler. Since using C# 6, I don't think I've created a property that maps directly to a hand-coded backing field. The new syntax is that versatile, and that clear.
Not having these language features earlier meant that we sometimes had to compromise on our designs. Instead of creating truly immutable types, we created types that had public properties with private setters (as I showed earlier in this article). Or, instead of compromising, we wrote out the much longer versions of C# that were consistent with our designs.
When I encounter such designs, I update those classes to use the modern syntax and express the intended design cleanly and concisely. It's a big improvement in readability. Furthermore, in the case where the private set was allowed, it enables the code to reflect the design more accurately. I still don't make it an explicit task to sweep a codebase looking for these former practices. But whenever I see them, I make the updates.
I am less aggressive about introducing the property initializer syntax into working code. However, if I am making changes to a class implementation, I make upgrades to the initialization code as needed. I'm more likely to make those changes if working tests cover the class.
A Look into the Future
One feature that didn't make the final release in C# 6 is primary constructors, which would have allowed you to create the Person class using an even more concise syntax:
// Primary constructors were dropped from C# 6
public class FuturePerson(string first, string last, DateTime birth)
{
public string FirstName { get; } = first;
public string LastName { get; } = last;
public DateTime DateOfBirth { get; } = birth;
}
Notice how the proposed feature extends the syntax for auto property initializers and read-only auto properties, and combines the constructor method declaration with the class declaration.
This feature was dropped (or at least delayed). It would make some idioms even more concise; however, its original proposed syntax (shown above) would have made other important features under consideration harder to implement. In particular, pattern matching and record types would be somewhat more difficult to define. The ideas of primary constructors, pattern matching, and record types are all under consideration for a future version of C#. You can see some of the discussion of the possible paths in the January 2015 C# design notes. In addition, Neal Gafter has posted a draft specification for a possible implementation of record types in C#.
Both of these features represent very early thinking, and ultimately they may not be implemented. They aren't currently scheduled for any future release. However, they show that some of the ideas behind the enhancements for auto properties are part of a bigger theme to make C# a more productive language for modern development idioms.