21

Given a struct like this:

public struct SomeStruct
{
    public SomeStruct(String stringProperty, Int32 intProperty)
    {
        this.StringProperty = stringProperty;
        this.IntProperty = intProperty;
    }

    public String StringProperty { get; set; }
    public Int32 IntProperty { get; set; }
}

Of course, a compiler error is generated that reads The 'this' object cannot be used before all of its fields are assigned to.

Is there a way to assign values to the backing fields or the properties themselves, or do I have to implement properties the old-fashioned way with my own explicit backing fields?

svick
  • 236,525
  • 50
  • 385
  • 514
Daniel Schaffer
  • 56,753
  • 31
  • 116
  • 165
  • 1
    btw - it would be more idiomatic to use "int" and "string" than "Int32" and "String". – Marc Gravell Feb 06 '09 at 21:40
  • 2
    We use String/Int32, etc in all our code in the shop I'm in... can't say why, now that you bring it up - but I personally like the way it looks better. – Daniel Schaffer Feb 06 '09 at 21:49
  • For S&G, regarding the previous 2 comments: http://stackoverflow.com/questions/62503/c-int-or-int32-should-i-care – Daniel Schaffer Feb 06 '09 at 21:51
  • Re comment on my post - actually, I was already maxed at the time, so I only got +15 rep – Marc Gravell Feb 07 '09 at 12:45
  • possible duplicate of [Automatic Properties and Structures Don't Mix?](http://stackoverflow.com/questions/420433/automatic-properties-and-structures-dont-mix) – nawfal Jun 03 '13 at 17:58

2 Answers2

45

Prior to C# 6, you need to use the "this" constructor in this scenario:

public SomeStruct(String stringProperty, Int32 intProperty) : this()
{
    this.StringProperty = stringProperty;
    this.IntProperty = intProperty;
}

Doing this calls the default constructor and by doing so, it initializes all the fields, thus allowing this to be referenced in the custom constructor.

Edit: until C# 6, when this started being legal; however, these days it would be much better as a readonly struct:

public readonly struct SomeStruct
{
    public SomeStruct(string stringProperty, int intProperty)
    {
        this.StringProperty = stringProperty;
        this.IntProperty = intProperty;
    }

    public string StringProperty { get; }
    public int IntProperty { get; }
}
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • What is the difference between using backing fields in the constructor and using auto-properties directly? I just can't wrap my head around the question. I think constructor is used to initialize fields, and auto-property is methods of setter and getter. So why should we put auto-properties in a constructor? –  Nov 04 '22 at 02:30
  • @K.K because they're read-only in this case - they only have a `get;`, so the field is marked `readonly` and they can *only* be assigned via the constructor – Marc Gravell Nov 04 '22 at 07:35
0

If a structure is going to have, and its users will expect it to have, all three of the following characteristics:

  1. Its entire state is encapsulated in some particular fixed set of readable members
  2. An instance may be readily created in which those members have any combination of values which are valid for their respective types.
  3. A default instance of the type should have all of those members set to the default values of their respective types.

the type should expose its members as fields. The above requirements mean a struct won't be able to do anything an exposed-field struct can't do, and will also mean that if code doesn't hit any threading hazards the struct will be able to do anything an exposed-field struct can do, albeit perhaps more slowly and with more threading hazards.

If a struct Foo has fields f1 and f2, and a constructor which sets those fields in that order, and if fooExpr is some sort of expression of type Foo [perhaps a variable, field, array reference, property, or whatever] the statement:

myFoo.f2 = someValue;

will only be allowed in cases where one could legally say

myFoo = new Foo(myFoo.f1, someValue);

and in all circumstances where the first form is allowed and the behavior of the second form has defined semantics, they will behave identically. Thus, trying to "encapsulate" the properties of Foo doesn't really accomplish anything except make the code more cumbersome to write, less clear, and slower to execute.

supercat
  • 77,689
  • 9
  • 166
  • 211
  • That's not quite true. Firstly, in a release build, the JIT compiler is likely to do inlining, probably removing any performance difference. But secondly, if you wrap fields as properties, you're protecting yourself against future changes to the struct: If later on, you need to add some logic to a field, that implies replacing the field with a property. If the field was already encapsulated with a property, then there's no change to the public interface, which removes a potential source of regression bugs. – Simon Robinson Jan 11 '14 at 16:52
  • @SimonRobinson: If the three restrictions I listed in my answer are part of a struct's contract, what *useful* logic could a property or constructor add without violating the contract? My personal philosophy is that structures should either represent objects (in which case they should be immutable) or aggregations of variables (in which case they should behave like aggregations of variables). – supercat Jan 13 '14 at 15:24
  • I guess if you are treating a struct as just an aggregation of variables then you would be correct, there would be no additional logic required. I was thinking mainly of logic to check the validity of values being set - but on closer reading of your answer I see your 2nd restriction rules that out. My main concern would be that even if you think values can be unrestricted when you write the struct, you might still find later on find restricting values is better. Or you might wish to change the internal representation (eg. make a field lazy-evaluated). – Simon Robinson Jan 14 '14 at 15:53