Is there a reason we have to set the field in the set accessor in expression body?

[tacosontitan]

I'm just curious if there's a reason we still have to specify x = value when using the lambda operator in the expression body? For example, my current employer requires underlying fields for properties instead of utilizing auto-properties due to binary serialization issues. So I consistently have to type something like:

private string _someField;
public string SomeProperty { get => _someField; set => _someField = value; }

I know we can infer that the consumer is intending to set the underlying field to the incoming value:

public string SomeProperty { get => _someField; set => _someField; }

But does this lead to unexpected behaviors? I know the LDT has a reason for everything they do so I figure here is the best place to ask.

Oh, if this was implemented in a version beyond 7.2 then ignore me. 😄

[HaloFour]

I know we can infer that the consumer is intending to set the underlying field to the incoming value:

Non-auto-properties don't have an underlying field. They are a totally self-contained member and the accessor is expected to perform any assignments. The return type for a set access is void so any result from an expression would just be discarded. You're expected to put a statement in the accessor to actually make the assignment to a field.

There are proposals out there to blur the line between auto-properties and normal properties, however if you are required to explicitly name your fields due to binary serialization concerns then they won't help. Although you should be able to use field-targeting attributes to instruct the serializer/deserializer to give that generated field a different name, I think.

[tacosontitan]

See, as I said, a reason for everything 👍🏻