The `field` Keyword in C# 13 — Cleaner Auto-Property Logic with Compiler-Generated Backing Fields

The field Keyword in C# 13 — Cleaner Auto-Property Logic with Compiler-Generated Backing Fields Level: Advanced Tags: #csharp #dotnet #csharp13 #properties #autoproperty #fieldkeyword In C# 13, the language introduces a new contextual keyword: field, which allows developers to interact directly with the compiler-synthesized backing field of an auto-implemented property. This feature is part of C# 13’s preview features (GB), and available with .NET 9. You must enable it via: preview The field keyword enables more precise control over property accessors, while maintaining the concise syntax of auto-properties. What Problem Does It Solve? Previously, to enforce logic like null-checking, you had to convert an auto-property into a full property with an explicit backing field: private string _name; public string Name { get => _name; set => _name = value ?? throw new ArgumentNullException(nameof(value)); } This breaks encapsulation, adds noise, and requires declaring _name manually. C# 13 Solution: Use field Instead Now, you can write: public string Name { get; set => field = value ?? throw new ArgumentNullException(nameof(value)); } This keeps the auto-property feel, but gives you a hook into the set accessor for validation, transformation, or other logic. Example: Clean Business Rule Injection public string Email { get; set => field = value?.ToLowerInvariant() ?? throw new ArgumentNullException(nameof(value)); } field refers to the backing field generated by the compiler You don’t need to declare it manually It works just like _email would, but safer and cleaner Summary of Behavior Feature Supported? Use field in set accessor ✅ Yes Use field in get accessor ✅ Yes Omit one or both accessors ✅ Supported Use with expression-bodied properties ✅ Supported Use in constructors ❌ Not applicable Warnings & Ambiguities If you declare a field named field, you may hit shadowing issues inside property accessors. Disambiguate with: this.field // property keyword @field // actual field named "field" Example private string field; // user-declared field public string Name { get => this.field; // Refers to the compiler's backing field set => this.field = value; } To avoid confusion: avoid naming variables field in the same scope. Why Use field? Benefit Description Clean logic injection Validation, trimming, formatting in set Avoids extra member declaration No need for _name or similar Better source generation compatibility Tools can use field safely in templates Keeps the code DRY No duplication between property and field Learn More Auto-Implemented Properties C# 13 Preview Features Final Thoughts The field keyword in C# 13 is a small but powerful enhancement that makes auto-properties more flexible and less verbose. It strikes a balance between readability and expressive control, especially for library authors, architects, and developers writing business logic-heavy code. ⚠️ Use it thoughtfully — especially in teams where field name collisions may arise. But once mastered, it will make your property implementations simpler and more expressive. Written by: [Cristian Sifuentes] – Property Design Specialist | Refactoring Evangelist | Modern .NET Architect Have you tried field in C# 13 preview? Share your patterns, and let’s refine clean property logic together!

May 8, 2025 - 01:03

The `field` Keyword in C# 13 — Cleaner Auto-Property Logic with Compiler-Generated Backing Fields

Level: Advanced

Tags: #csharp #dotnet #csharp13 #properties #autoproperty #fieldkeyword

In C# 13, the language introduces a new contextual keyword: field, which allows developers to interact directly with the compiler-synthesized backing field of an auto-implemented property.

This feature is part of C# 13’s preview features (GB), and available with .NET 9. You must enable it via:

preview

The field keyword enables more precise control over property accessors, while maintaining the concise syntax of auto-properties.

What Problem Does It Solve?

Previously, to enforce logic like null-checking, you had to convert an auto-property into a full property with an explicit backing field:

private string _name;

public string Name
{
    get => _name;
    set => _name = value ?? throw new ArgumentNullException(nameof(value));
}

This breaks encapsulation, adds noise, and requires declaring _name manually.

C# 13 Solution: Use `field` Instead

Now, you can write:

public string Name
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(value));
}

This keeps the auto-property feel, but gives you a hook into the set accessor for validation, transformation, or other logic.

Example: Clean Business Rule Injection

public string Email
{
    get;
    set => field = value?.ToLowerInvariant()
        ?? throw new ArgumentNullException(nameof(value));
}

field refers to the backing field generated by the compiler
You don’t need to declare it manually
It works just like _email would, but safer and cleaner

Summary of Behavior

Feature	Supported?
Use `field` in `set` accessor	✅ Yes
Use `field` in `get` accessor	✅ Yes
Omit one or both accessors	✅ Supported
Use with expression-bodied properties	✅ Supported
Use in constructors	❌ Not applicable

Warnings & Ambiguities

If you declare a field named field, you may hit shadowing issues inside property accessors.
Disambiguate with:

  this.field       // property keyword
  @field           // actual field named "field"

Example

private string field; // user-declared field

public string Name
{
    get => this.field; // Refers to the compiler's backing field
    set => this.field = value;
}

To avoid confusion: avoid naming variables field in the same scope.

Why Use `field`?

Benefit	Description
Clean logic injection	Validation, trimming, formatting in `set`
Avoids extra member declaration	No need for `_name` or similar
Better source generation compatibility	Tools can use `field` safely in templates
Keeps the code DRY	No duplication between property and field

Learn More

Final Thoughts

The field keyword in C# 13 is a small but powerful enhancement that makes auto-properties more flexible and less verbose. It strikes a balance between readability and expressive control, especially for library authors, architects, and developers writing business logic-heavy code.

⚠️ Use it thoughtfully — especially in teams where field name collisions may arise. But once mastered, it will make your property implementations simpler and more expressive.

Written by: [Cristian Sifuentes] – Property Design Specialist | Refactoring Evangelist | Modern .NET Architect

Have you tried field in C# 13 preview? Share your patterns, and let’s refine clean property logic together!