Using readonly field instead of private setters in struct

Question

This is supposed to be an immutable structure representing a time-stamped value. Since it represents a physical measurement, it cannot change, and I want to make sure it really doesn't change accidentally at runtime.

public struct Sample
{
    public TimeSpan Time { get { return _time; } }
    private readonly TimeSpan _time;

    public Double Value { get { return _value; } }
    private readonly Double _value;

    public Sample(TimeSpan time, Double value) : this()
    {
        _time = time;
        _value = value;
    }
}

I have heard a lot about "properties are better than fields", and it's common to see the following idiom:

public Double Foo { get; private set; }

But I wonder:

1. Does it make a difference? I feel I prefer the current, field-based form, but maybe I am missing something...
2. In case it does, which one is preferrable, regarding immutability (and also other characteristics)?

Answer 1

Thought I'd chime in:

You've stated that this should be an immutable struct. With that in mind, the solution you want is the one with the backed readonly fields.

I feel explicitly stating intent in code is good. You say that you want immutability, then write the code so.

If you were to opt for the property only solution then consider what would happen if some other developer came along and misunderstood your original intent (because this time it wasn't fully explicit)

With the properties you are stating - The public consumers of my struct may not mutate it but the struct itself can.

With the readonly fields you are stating - The public consumers of my struct may not mutate it and neither may the struct itself.

The latter is correct in regards to your spec.

To briefly summarise:

"Does it make a difference?" Yes, your intent is different between the two. Yes, one allows mutation after the point of declaration, one does not.

"In case it does, which one is preferrable, regarding immutability (and also other characteristics)?" For immutability, the readonly option.

Answer 2

Using the readonly keyword ensures that the value can only be set as part of the declaration

private readonly bool value = true;  

or in the constructor of the same class.

A private set can be called from anywhere in the class. So one could say it is safer to use the readonly if you need to ensure that the value won't be changed anywhere (by mistake e.g).

Using the private set aproach will lead to less code and in increased readability.

Answer 3

"properties are better than fields" only says that you should prefer public properties over public fields. It does not say that auto properties are better than properties with explicit backing fields.

• Readonly backing fields have stronger immutability guarantees
• Auto properties require a call to :this() in the constructor. This is a bit ugly and potentially reduces performance a bit.
• Auto properties are less code

Personally I use auto properties if I'm lazy, but readonly backing fields when I aim for good code.

---

I believe C# 6 will add a feature for "readonly properties" that combines the advantages of these alternatives.

Answer 4

Class properties have significant advantages over class fields, and a class which exposes autoproperties rather than fields can easily be changed to use "normal" properties later without affecting any of the calling code. Structure properties do not offer those same advantages, however. The only times a struct property has a real advantage over a structure field are when the property is defined as doing something that could not be accomplished by reading a field (in which case an auto-property wouldn't be suitable), when the structure needs to implement an interface that exposes a property, or when the struct has to be usable with code that accesses properties via Reflection.

A structure is, fundamentally, a collection of independent variables stuck together with duct tape. Given variables X and Y of some structure type, the statement X=Y will mutate X by overwriting all of its instance fields with the values of the corresponding fields in Y. This mutation is done without regard for whether any of the fields are public or private, read-only or mutable, and there's no way the code for a struct can do anything about it. If a structure allows all its fields to be read, and allows the creation of a struct instances with any combination of field values, then the structure will be semantically equivalent to a structure which simply exposes its fields, and it may as well do so. Only if a structure has private fields whose values cannot be observed, or imposes restrictions on the values fields can take, is it helpful to do anything else. Otherwise, the fact that struct fields may be overwritten outside the struct's control limits the value of making structures pretend to be immutable.