Language Proposal: fieldof Keyword for C#

[rudolfstepan]

This proposal introduces a new language keyword fieldof(...) in C#. It enables safe, typed, and controlled access to the backing field of auto-properties without triggering associated logic such as OnPropertyChanged or OnPropertyChanging.

This is particularly useful in scenarios involving MVVM patterns, Undo/Redo operations, serialization, and validation, where internal state changes should not result in external behavioral side-effects.

More to this, please follow up here to my repo:

https://github.com/rudolfstepan/proposals/blob/main/fieldof_proposal/docs/fieldof_proposal_en.md

[HaloFour]

See: #8704

[CyrusNajmabadi]

The above seems like it heavily overlaps the other discussion/design. It would be better to keep the concerns together when evaluating if we want to take on any of this.

[333fred]

If you were to read through the linked proposal, you'd note that #8704 (comment) mentioned that fieldof(), as you proposed here, was considered and rejected by LDM.

[jnm2]

Side note: The use of AI in conversation with other people can present a barrier. I can see that the AI doesn't quite get the point, and yet it fills so much space with so many words.

[rudolfstepan]

1rst, thanks for this great conversation. I will try to answer all your arguments:

• Objection 1: “It breaks encapsulation – backing fields are implementation details.”

Counter:
We already allow controlled access to the backing field with field in set (C# 12).
fieldof simply extends this access in a clean and compiler-safe way.

Example:

set => field = value; // already allowed
fieldof(this.SomeProperty) = value; // same idea, outside property

• Objection 2: “You can just define a private field manually.”

Counter:
Yes, but this leads to redundant code, inconsistent naming (_propName), and weak refactor support.
fieldof is clean, unambiguous, and tools can recognize it.

Example:

// instead of maintaining _price and syncing it:
fieldof(this.Price) = 42;

• Objection 3: “It encourages bypassing validation in the property setter.”

Counter:
Exactly – that’s the point when you're inside your own class and want full control (e.g. during deserialization, undo, or initialization).
You don’t always want OnPropertyChanged firing.

Example:

fieldof(this.IsDirty) = false; // silent reset, no side effects

• Objection 4: “It complicates readonly/init/immutable behavior.”

Counter:
Let the compiler restrict fieldof usage based on property type – same as with init or readonly.
It doesn’t need to be allowed everywhere.

Example:

// allowed on get/set
public string Name { get; set; }

// disallowed on init-only
public string Id { get; init; } // compiler error for fieldof

• Objection 5: “It opens up too much access.”

Counter:
We can add [field: ExposeField] as an opt-in attribute.
By default, fieldof is only allowed inside the declaring type – no public exposure unless explicitly requested.

Example:

[field: ExposeField]
public int Score { get; set; }

• Objection 6: “It’s a niche use case.”

Counter:
Not really. Anyone doing MVVM, serialization, object cloning, or performance-critical updates runs into this.
Right now, they use ugly workarounds like reflection or duplicated fields.

Example:

foreach (var state in savedStates)
fieldof(this.GetType().GetProperty(state.Key)) = state.Value;

• Objection 7: “The name ‘fieldof’ is confusing.”

Counter:
It’s consistent with nameof, typeof, and scoped.
And it clearly signals intent: I want the field, not the logic.

Conclusion:
fieldof solves a real-world pain point in a safe, familiar, and non-intrusive way – without breaking language principles or requiring new concepts.

Also, just to clarify: I'm not strictly attached to the name fieldof.
It simply felt like the natural choice, given how it mirrors nameof and is conceptually tied to the existing field keyword introduced in C# 12 for auto-properties.

My goal is not to expose arbitrary fields or bypass property logic recklessly, but to give developers a clean and controlled way to access the compiler-generated backing field (e.g. <>Price) – the same field that already exists under the hood for auto-properties.

This would allow us to:

• continue using the modern get; set; syntax,
• benefit from the simplicity of auto-properties,
• and still have precise control where necessary (e.g. silent state updates, undo/redo, deserialization),
  without giving up on this great language feature just because we occasionally need to bypass the setter logic.

If there’s a better or more idiomatic way to achieve this behavior while retaining auto-properties and compiler-generated fields, I’m absolutely open to suggestions.

I simply want a way to combine the elegance of auto-properties with the flexibility of manual field control – in a safe, compiler-approved manner.

Thanks again for taking the time to consider the proposal.

[333fred]

I'm going to lock this issue. Again, this is a duplicate. Please feel free to chime in on #8704, which is the discussion issue for the championed fieldof proposal. Splitting the discussion across multiple issues does nothing but make it harder to track where ideas were discussed for everyone in the future.