C# field vs. property [duplicate]

Answer 1

I found out there is also a disadvantage to properties. They cannot be accessed by reference if they are of a value type. Why is this

Because under the covers, a property is just a method. If you look at the IL, you'll see methods like get_PropertyName and set_PropertyName. The problem with that is in order to support working with references, you would need to be able to return a reference for a method.

public ref T MyProperty
{
    get
    {
         return ref _underlyingField;
    }
}

Update: Starting in C# 7.0, this is possible using the syntax describe above.

Remainder of previous answer:

This of course, is something entirely possible in the CLR; but not exposed by the C# language.

Though it is possible, the CLR needs some tweaks to keep it as verifiable. The syntax for the property would have to support it to.

However, is any of that useful? As you stated, a field can do it. If you need it; use a field. Supporting it would take a lot of work. There are probably a very few cases where it is appropriate; and would create many cases where just using a field might have been better in the first place.

Answer 2

Properties are just sugar-coating syntax for a getX() and setX() method. It looks and acts like a field, but it's really just two methods. The reason why the auto-property was added was to avoid the repetition of having to create a field and creating a standard getter and setter for the property, and to make it much simpler to allow changing the implementation without changing the interface.

The reason they can't be accessed by reference if they are a value type is because value types are generally on the stack and because you're just calling a method. The getter in the property has to be called and the returned value has to be pushed on the stack before it can be referenced.