OdeToCode IC Logo

C# 6.0 Features Part I : Property Initializers

Monday, August 4, 2014

With a new release of the C# language approaching, it’s also time to look at new features for C#.

First up is the ability to use an initialization expression with an automatically implemented property.

Currently, a constructor is required if you want to create objects using an auto-property and initialize an auto-property to a non-default value.

In C# 6.0, the ability to use an initializer with the auto-property means no explicit constructor code is required.

public class User
    public Guid Id { get; } = Guid.NewGuid();
    // ...

Another benefit of the syntax is how an initialized auto-property only requires a getter, the set method is optional. With no setter, immutability is easier to achieve.  

The property initialization syntax also plays well with another new feature for C# 6, the primary constructor syntax. We’ll look at primary constructors in the next post for this series.

Gravatar Jon Preece Monday, August 4, 2014
I don't like the way C# syntax is going right no, but perhaps thats just me.
Gravatar Jesse C. Slicer Monday, August 4, 2014
I'm thrilled with automatic property initialization and immutability. I've always been a proponent of using "readonly" for declarative intent (and potential optimization) and that has put the kibosh on using automatic properties in many situations. Some folks think "private set" is good enough immutability, but it always had a funny smell to me to use for immutable design. Pretty much all of C#6 looks great to me, but I'm not sure I really understand the benefit of "Indexed members and element initializers". The examples I see don't look much different than collection initialization syntax.
Patrick Monday, August 4, 2014
Taking both of the above comments into consideration (because I like immutability and a more consistent syntax), I would have preferred to have: public class User { public User() { Id = Guid.NewGuid(); } public Guid Id { get; } // ... } My guess is that the "primary constructors" (http://damieng.com/blog/2013/12/09/probable-c-6-0-features-illustrated) feature doesn't play well with this syntax, so its not an option.
Gravatar Mark Monday, August 4, 2014
I'm a little confused why a constructor is necessary currently, isn't: public Guid Id { get { return Guid.NewGuid(); } } the same as the notation with the initializer?
Gravatar Greg Monday, August 4, 2014
Any plans to eliminate the requirement to double initialize structures with auto properties? Right now if a struct contains an auto property, the constructors are required to call the default constructor (e.g. public Point(int x,int y) : this() { this.x = x; this.y = y }) to essentially double initialize the backing fields even if the properties are explicitly initialized in the constructor.
Gravatar Scott Allen Monday, August 4, 2014
@Mark: Yes, that's the same end result. It makes a little more sense when you want to assign some incoming parameter from a ctor. That will be the next post in the series. @Jesse: I think the indexed members have been cut from v6. @Jon: the jury is still out here, too :)
Gravatar Scott Allen Monday, August 4, 2014
@Greg: It looks the same with v6. I think this is for the special case of a struct being used without the new keyword, or when initializing an array of some struct type. It's the "all bits are zero" default that doesn't seem avoidable.
Gravatar Todd Monday, August 4, 2014
@mark no I believe it is different, each time you call your getter a different GUID is returned, bit I believe the initializer will set the getter to the same GUID.
Gravatar Greg Monday, August 4, 2014
@mark I agree with Todd definately different behavior. The getter is called each time you ask for it so a different guid would be returned each time.
Gravatar scott Monday, August 4, 2014
Greg, that's correct. Disregard my previous comment, I didn't look and think at the same time. Big difference.
Gravatar Phil Tuesday, August 5, 2014
It's nice to see C# starting to catch up with F# on class syntax, here's the equivalent F# implementation: type User () = member val Id = Guid.NewGuid() Note: in F# the type of the property can be inferred from the expression.
Gravatar Kent Boogaart Tuesday, August 5, 2014
I've never used auto-properties except in spikes or throwaway code because I don't like the way they hide the memory footprint of the object. Am I the only one who just wants to be able to look at a complete list of fields for a type without having to manually determine which properties have auto-generated backing fields and which do not? I feel like the syntax is backwards: instead of properties with auto-backing fields, perhaps we should be able to declare fields with auto-generated properties...? Too late now, I know.
Comments are closed.