[7/30/2015] This article was written against a pre-release version of C# 6.0. Be sure to check out the list of my five favorite C# 6.0 features for content written against the release!

[Update: 1 Oct 2014] It has been said that if something sounds too good to be true, it probably is. The adage apparently even applies to the proposed C# 6 features that I was excited about. I’m sad to say that it was announced today that primary constructors would not be part of C# 6. It also sounds like there will be some changes around readonly auto-implemented properties.

As much as I prefer working in F#, I can’t ignore the fact that most of my work is still in C#. With Visual Studio “14” now in CTP 2 with some of the C# 6.0 features, it makes sense to take a more serious look at what’s in the works or has already been implemented. As such, I’ll be spending the next few articles describing some of these features and capturing my initial thoughts about them. In this article I’ll cover auto-implemented property initializers and primary constructors. Although these are separate features I suspect they’ll often be used together so it seems appropriate to discuss them at the same time. As with any CTP, everything I examine here is definitely subject to change but information regarding language feature implementation status can be found on the Roslyn Codeplex page.

Anyone familiar with F# should immediately recognize both of these features because they’ve been available in F# for years. I think both of these features are a nice addition to C# because they have the potential to greatly reduce the language’s verbosity and bring some feature parity with F# but I still like F#’s approach better.

Auto-Implemented Property Initializers

Auto-implemented property are being enhanced in two ways: they can be initialized inline, and you can define them without a setter. With inline initialization we can provide an initial value for the auto-implemented property without having to manually set the property via a constructor. For instance, if we have a Circle class with an auto-implemented Radius property we could initialize it as follows:

public class Circle
{
    public int Radius { get; set; } = 0;
}

What’s nice about the initializer syntax is that it sets the generated backing field rather than explicitly invoking the setter through a constructor or other mechanism. This feature also allows us to define a getter-only auto-implemented property, like this:

public class Circle
{
    public int Radius { get; } = 0;
}

As much as I appreciate these enhancements and will happily embrace them when they’re available, it bugs me that the type is still required in the property definition. It would be really nice to have the C# compiler infer the type from the initializer like F# does but for now, this is a nice start.

Primary Constructors

Primary constructors provide a mechanism by which a class (or struct) can accept parameters without a formal constructor declaration by including them in the class definition. The values defined in the primary constructor are scoped to the class but their lifetime is limited to class initialization by default. This makes them perfect for setting fields or initializing auto-implemented properties. Here we include a primary constructor for the Circle class and use it to initialize the Radius property:

public class Circle(int radius)
{
    public int Radius { get; } = radius;
}

The scoping rules for the values identified in the primary constructor are one place that C#’s primary constructors differ from F#’s (yes, I prefer F#’s approach here, too). As I previously mentioned, by default the primary constructor values are available only during class initialization. This means that while you’re free to use them for initialization, you can’t reference them in any methods. For instance, if we wanted to include a GetArea method our Circle class, the following approach would be invalid:

public class Circle(int radius)
{
    public int Radius { get; } = radius;

    public double GetArea()
    {
        return Math.PI * Math.Pow(radius, 2);
    }
}

It would be really nice if we could include an access modifier or attribute instructing the compiler to automatically generate a field but for now, it looks like we’ll have to make due with initialization scoping.

For cases where you need to do more than some basic initialization (such as parameter validation), it’s possible to define a primary constructor body by wrapping the statements in a pair of curly braces (of course, more braces) within the type definition.

As with the auto-implemented property initializers, I really appreciate this feature but wish it would go a bit further. Generally speaking, though, I see this as a positive feature for the language.