DEV Community

Cristian Sifuentes
Cristian Sifuentes

Posted on

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

#csharp #dotnet #programming #backend

The_field_Keyword_in_CSharp13

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:

<LangVersion>preview</LangVersion>
Enter fullscreen mode Exit fullscreen mode

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));
}
Enter fullscreen mode Exit fullscreen mode

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));
}
Enter fullscreen mode Exit fullscreen mode

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));
}
Enter fullscreen mode Exit fullscreen mode
  • 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"
Enter fullscreen mode Exit fullscreen mode

Example 

private string field; // user-declared field

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

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!

Top comments (0)