A question about how properties work internally and null-conditional operators

Question

As I read before in some of this forums thread (here and here) properties are just syntactic sugar. This 2 implementations are the same after compilation:

class Item
{
    string _name;

    public string Name
    {
        get => _name;
        set => _name = value;
    }      
}

class Item
{
    string _name;

    public string GetName() => _name;

    public void SetName(string name) => _name = name;        
}

If my hypothesis above it's true, why I can do this:

class Works
{
    Item _item;

    void SetItemName(string name) => _item?.SetName(name);
}

But I can't do this:

class Fails
{
    Item _item;

    void SetItemName(string name) => _item?.Name = name;
}

In the last example, _item?.Name = name produces this compiler error:

The left-hand side of an assignment must be a variable, property or indexer

"just syntactic sugar" - no, they're not. You can use ildasm to disassemble your two examples and compare them. They are *not* exactly the same. — Damien_The_Unbeliever, Nov 23 '20 at 09:52
N.B. As an aside, a property definition can exist on its own, it doesn't need a private field behind it e.g. `public string Name { get; set; }` will do exactly the same as the property in your first `Item` class. — ADyson, Nov 23 '20 at 09:54

Jon Skeet · Accepted Answer · 2020-11-23T10:01:01.083

Yes, properties are effectively syntactic sugar for methods with extra metadata, in terms of the generated code.

But that doesn't mean that the language rules for properties are always the same as for methods. The left-hand side of an assignment operator has to be a variable, property or indexer - but the expression _item?.Name is classified as a value rather than a variable. The language could have been designed to allow this, without changing how properties themselves work at all, but this is what we've got at the moment. (It's possible that this could change in the future, too.)

In other words, this isn't about how properties are implemented internally, but about the C# rules that govern how they can be used - and in particular, how the assignment operator works. In fact, you can take properties out of the equation entirely - if you use a public field in Item instead of a property, you'll see exactly the same error.

This isn't new to the null-safe dereferencing operator, either. Consider this example:

struct MutableStruct
{
    public int Value { get; set; }

    public void SetValue(int value) => Value = value;
}

class Test
{
    static void Main()
    {
        Method().SetValue(10); // Valid, but not useful
        Method().Value = 10; // Invalid
    }

    static MutableStruct Method() => new MutableStruct();
}

Here Method().Value = 10; isn't valid because the Method() expression evaluates to a value, not a variable (or a property or indexer).

Thanks you for this explanation. Just a question, i've been searching for the web but... what do you refer about "extra metada"? — Rubén Cantón, Nov 23 '20 at 10:30
@RubénCantón: Basically metadata within the IL that says "the two methods `get_Name` and `set_Name` are the implementations for the `Name` property". The compiler may also add attributes for some aspects such as for the backing field for auto-implemented properties. — Jon Skeet, Nov 23 '20 at 10:36

A question about how properties work internally and null-conditional operators

1 Answers1