views:

1020

answers:

1

If I define a struct in C# using automatic properties like this:

public struct Address
{
    public Address(string line1, string line2, string city, string state, string zip)
    {
        Line1 = line1;
        Line2 = line2;
        City = city;
        State = state;
        Zip = zip;
    }

    public string Line1 { get; protected set; }
    public string Line2 { get; protected set; }
    public string City { get; protected set; }
    public string State { get; protected set; }
    public string Zip { get; protected set; }
}

When I attempt to build the file, I get a compilation error saying "The 'this' object cannot be used before all of its fields are assigned to". This can be solved by changing the constructor to make a chained call to the default constructor like this:

public Address(string line1, string line2, string city, string state, string zip): this()
{
    Line1 = line1;
    Line2 = line2;
    City = city;
    State = state;
    Zip = zip;
}

My question is, why does this work, and what is happening? I have a guess, and I tried to prove it by looking at IL, but I'm only kidding myself if I think I can break down IL. But my guess is, auto properties work by having the compiler generate fields for your properties behind the scenes. Those fields cannot be accessed through code, all setting and getting must be done through the properties. When creating a struct, a default constructor cannot be explicitly defined. So behind the scenes, the compiler must be generating a default constructor that sets the values of the fields that the developer can't see.

Any and all IL wizards are welcome to prove or disprove my theory.

+17  A: 

this() makes sure that the fields are definitely assigned as far as the compiler is concerned - it sets all fields to their default values. You have to have a fully constructed struct before you can start accessing any properties.

It's annoying, but that's the way it is. Are you sure you really want this to be a struct though? And why use a protected setter on a struct (which can't be derived from)?

Jon Skeet
The protected set is habit. I don't make many structs. And this isn't from actual code I'm writing, I wrote it specifically to illustrate the point of my question. But Addresses are immutable and a good choice for structs. People move to new addresses, addresses don't change.
NerdFury
Immutable != struct. It doesn't feel very struct-y to me. It's not necessarily a *bad* choice, but it's not one I'd make. I'd make the immutability clearer though: use a "normal" (read-only) property and a readonly field. It's a shame that automatic properties can't have "readonly" setters (cont)
Jon Skeet
... which would only be accessible in constructors, in the same way as assigning to a readonly field. The compiler could then generate a read-only field behind the scenes, and convert setter access to field access directly.
Jon Skeet