[Proposal]: New expression for access backing field of auto-implemented property

[Flithor]

New expression for access backing field of auto-implemented property: fieldof()

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Make programmer to access the backing field of auto-implemented property when necessary to be use it with ref param.

Motivation

We cannot use property with ref param. If I want to use a property value in some place, I should to write a full property.

Detailed design

//auto-implemented property
public int MyProp { get; set; }

//method with ref param:
pubic void MyMethod(ref int param) { ... }

//error:
MyMethod(ref MyProp);
=========
//use it:
MyMethod(ref fieldof(MyProp));

//equals:
private int myProp;
public int MyProp
{
    get => myProp;
    set => myProp = value;
}
MyMethod(ref myProp);

Drawbacks

May will make readonly property be modifiable.
But can limit it cannot use fieldof on readonly propery.

Alternatives

Unresolved questions

Design meetings

[CyrusNajmabadi]

Make programmer to access the backing field of auto-implemented property when necessary to be use it with ref param.

At this point i would say that you shouldn't have an auto-prop.

MyMethod(ref fieldof(MyProp));

This is particularly concerning, because it makes how a property works no longer an implementation detail. For example, you couldn't change your property from an auto-prop to a completely computed prop as that would break anyone that did fieldof on it.

The reason to use a property in the first plcae, and not just use a field, is entirely because the impl should be hidden and can be updated/replaced in the future without breaking anything that would change this.

If you want ot be able to pass as a ref, and you want people to be able to use the field directly, then there is no value in usign a property. Just replace the property with a field. Now it will all work, and will have all the same limitations as you'd have if you used fieldof()

[CyrusNajmabadi]

Sorry, I don't really understand what you're asking. Can you clarify?

[Rubidium37]

Auto-properties are meant for code compactness and readability.
Explicit backing fields were the norm when auto-prop did not exist.

Now, with C# 13, the new field keyword has been proposed to declare partial auto-properties (where one of the accessors is implicitly generated by the compiler) or to keep complex property logics but without declaring an explicit backing field, that would clutter the source code.
A secondary side-effect of explicit backing field is that their usage is slightly error-prone, where one can copy/paste some code from one property to another and accidentally keep the name of the wrong field.

Moreover, the field keywords makes it very clear the source/target of a value, while the name of a field must be processed by the developer and somehow compared to the property name in order to establish that it is the backing field, or not.

Having a fieldof keyword would indeed allow to avoid explicit backing fields completely.

IMHO, it should act exactly like the explicit backing field, that normally is private (or rarely protected, or maybe internal).
Indeed, it is the responsibility of the property author (and his coworkers) to determine when the direct field access is right or wrong, exactly like with explicit backing fields.

About the readonly access, the compiler could enforce it based on what property accessors contain explicit code or depending on annotations on the property.
As an effect, passing the field to a ref or out parameter could be denied if the property is decorated with [field: ReadOnly] and the invocation is not inside the init accessor while passing to a in parameter should be allowed everywhere regardless of the annotation.

[333fred]

This was discussed in ldm, see https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-01-15.md#fieldof.