{"id":2280,"date":"2026-02-20T20:27:34","date_gmt":"2026-02-20T20:27:34","guid":{"rendered":"https:\/\/www.w3computing.com\/articles\/?p=2280"},"modified":"2026-02-20T20:27:42","modified_gmt":"2026-02-20T20:27:42","slug":"semi-auto-properties-field-keyword-csharp","status":"publish","type":"post","link":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/","title":{"rendered":"Semi-Auto Properties and the field Keyword in C#"},"content":{"rendered":"\n

1. Introduction<\/h2>\n\n\n\n

Auto-properties were a welcome addition back in C# 3.0. Instead of declaring a private backing field, writing a getter that returns it, and writing a setter that assigns to it, you could collapse all of that into a single line. Clean, fast, done.<\/p>\n\n\n\n

But that convenience came with a hard ceiling. The moment you needed anything<\/em> beyond a straight get\/set \u2014 a range check in the setter, a default value computed at first access, a bit of transformation before storing a value \u2014 the compiler-generated backing field became completely inaccessible to you. Your only option was to abandon the auto-property entirely: declare an explicit _value<\/code> field, re-wire the getter and setter by hand, and end up with four to eight lines of boilerplate where one used to live. For something as common as input validation, that felt like a disproportionate tax.<\/p>\n\n\n\n

C# 13 addresses this with the field<\/code> keyword and the concept of semi-auto properties<\/em>. The idea is straightforward: let the compiler still generate the backing field, but give you access to it inside the property body through the contextual keyword field<\/code>. You keep the convenience of not naming the field yourself, and you get the flexibility to add logic around it.<\/p>\n\n\n\n

It’s a small addition to the language. The impact on day-to-day code is anything but.<\/p>\n\n\n\n

2. A Quick Refresher: Auto-Properties vs. Full Properties<\/h2>\n\n\n\n

Before diving into field<\/code>, it’s worth grounding ourselves in the two patterns it sits between, because semi-auto properties only make sense as a middle ground once you feel the friction at both ends.<\/p>\n\n\n\n

Auto-properties<\/strong> are the ones you write without thinking:<\/p>\n\n\n

public<\/span> class<\/span> Product<\/span>\n{\n    public<\/span> string<\/span> Name { get<\/span>; set<\/span>; }\n    public<\/span> decimal<\/span> Price { get<\/span>; set<\/span>; }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
The compiler generates a private backing field for each one behind the scenes. You never see it, you never touch it, and that’s the whole point. For simple data-carrier types, this is exactly what you want.<\/p>\n\n\n\n
The trouble starts when requirements creep in. Say Price<\/code> can’t be negative. Now you need to intercept the setter. And the moment you do that, auto-property syntax is no longer on the table:<\/p>\n\n\n
public<\/span> class<\/span> Product<\/span>\n{\n    private<\/span> decimal<\/span> _price;\n\n    public<\/span> string<\/span> Name { get<\/span>; set<\/span>; }\n\n    public<\/span> decimal<\/span> Price\n    {\n        get<\/span> => _price;\n        set<\/span>\n        {\n            if<\/span> (value<\/span> < 0<\/span>)\n                throw<\/span> new<\/span> ArgumentOutOfRangeException(nameof<\/span>(value<\/span>), \"Price cannot be negative.\"<\/span>);\n            _price = value<\/span>;\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
That’s a significant jump in verbosity for what is, conceptually, a very minor change in behavior. You’ve gone from one line to nine, and you’ve had to introduce a private field with a name you now have to maintain, keep consistent with any naming conventions your team follows, and make sure never collides with anything else. The logic itself \u2014 the actual interesting part \u2014 is just two lines buried in the middle.<\/p>\n\n\n\n
This is the gap that exists between auto-properties and full properties, and it’s a gap C# developers cross dozens of times in any reasonably sized codebase. Renaming a field during a refactor, keeping _price<\/code> and Price<\/code> in sync, making sure you didn’t accidentally reference the field directly somewhere and bypass the validation \u2014 none of it is hard, but all of it is noise.<\/p>\n\n\n\n
Semi-auto properties live exactly in this space. Same compiled output, far less ceremony.<\/p>\n\n\n\n
3. What Are Semi-Auto Properties?<\/h2>\n\n\n\n
The name “semi-auto property” isn’t an official C# specification term \u2014 it’s the shorthand the community and the C# team landed on to describe what this feature actually is: a property where the compiler still generates the backing field, but you write at least one accessor body yourself.<\/p>\n\n\n\n
The mechanism is simple. Inside any property accessor, you can now use the contextual keyword field<\/code> to refer to the compiler-synthesized backing field for that property. That’s it. No declaration, no naming, no private decimal _price<\/code> sitting above the property. The field exists because the compiler creates it, and field<\/code> is how you reach it.<\/p>\n\n\n\n
Here’s the Price<\/code> example from the previous section, rewritten as a semi-auto property:<\/p>\n\n\n
public<\/span> class<\/span> Product<\/span>\n{\n    public<\/span> string<\/span> Name { get<\/span>; set<\/span>; }\n\n    public<\/span> decimal<\/span> Price\n    {\n        get<\/span> => field;\n        set<\/span>\n        {\n            if<\/span> (value<\/span> < 0<\/span>)\n                throw<\/span> new<\/span> ArgumentOutOfRangeException(nameof<\/span>(value<\/span>), \"Price cannot be negative.\"<\/span>);\n            field = value<\/span>;\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
Nine lines down to seven, but more importantly, the backing field is gone. There’s nothing to name, nothing to keep in sync, and no risk of accidentally bypassing the property logic by referencing the field directly elsewhere in the class. The field<\/code> keyword is only accessible inside the property’s own accessors \u2014 it’s completely invisible to the rest of the type.<\/p>\n\n\n\n
It helps to think about the three property patterns as a clear spectrum:<\/p>\n\n\n\n
    \n
  • Auto-property<\/strong>: compiler writes both accessors and the backing field. You control nothing.<\/li>\n\n\n\n
  • Semi-auto property<\/strong>: compiler writes the backing field. You write one or both accessors, using field<\/code> to interact with it.<\/li>\n\n\n\n
  • Full property<\/strong>: you write everything \u2014 the backing field, both accessors, all of it.<\/li>\n<\/ul>\n\n\n\n
    Semi-auto properties don’t replace either end of that spectrum. A plain { get; set; }<\/code> with no extra logic should stay an auto-property. A property that needs two private fields, or that computes its value entirely from other properties with no storage at all, still warrants a full implementation. Semi-auto properties are specifically the answer to the case in the middle: you need a stored value, and<\/em> you need a little logic around it.<\/p>\n\n\n\n
    One thing worth noting early: field<\/code> is a contextual<\/em> keyword, not a reserved one. That distinction matters, and we’ll get into the specifics in the next section.<\/p>\n\n\n\n
    4. The field<\/code> Contextual Keyword \u2014 Syntax and Semantics<\/h2>\n\n\n\n
    Let’s get precise about how field<\/code> actually works, because there are a handful of rules and behaviors here that will save you from confusion later \u2014 especially around nullability, attribute targeting, and the contextual vs. reserved keyword distinction.<\/p>\n\n\n\n
    Contextual, Not Reserved<\/h3>\n\n\n\n
    field<\/code> is a contextual keyword, which means it only carries special meaning inside a property accessor body. Everywhere else in your code, field<\/code> is a perfectly valid identifier. You can have a local variable named field<\/code>, a parameter named field<\/code>, a method named field<\/code> \u2014 the compiler figures out from context which one you mean.<\/p>\n\n\n\n
    This was a deliberate language design decision. Making field<\/code> a fully reserved keyword would have been a breaking change for any codebase that already used field<\/code> as an identifier, which is not an uncommon thing in serialization code, reflection utilities, and ORM-related infrastructure. By keeping it contextual, the C# team avoided breaking existing code entirely.<\/p>\n\n\n\n
    That said, this creates one genuine footgun, which we’ll cover in detail in the gotchas section. For now, just keep in mind: if you have a parameter or local variable named field<\/code> inside an accessor, it will shadow the keyword. The compiler will warn you, but it won’t stop you.<\/p>\n\n\n\n
    Where field<\/code> Is Valid<\/h3>\n\n\n\n
    The field<\/code> keyword is valid inside the body of any of the following accessors:<\/p>\n\n\n\n
      \n
    • get<\/code><\/li>\n\n\n\n
    • set<\/code><\/li>\n\n\n\n
    • init<\/code><\/li>\n<\/ul>\n\n\n\n
      It is not valid anywhere else in the class body. You can’t reference it from a constructor, a method, another property, or an expression outside of these accessor bodies. This is by design \u2014 the whole point is that the backing field is encapsulated within the property itself.<\/p>\n\n\n\n
      You also don’t need to use field<\/code> in both accessors. These are all valid semi-auto properties:<\/p>\n\n\n
      \/\/ Only the setter uses field; getter has custom logic<\/span>\npublic<\/span> string<\/span> Slug\n{\n    get<\/span> => field.ToLowerInvariant().Replace(' '<\/span>, '-'<\/span>);\n    set<\/span> => field = value<\/span>.Trim();\n}\n\n\/\/ Only the getter uses field; setter is auto-generated<\/span>\npublic<\/span> DateTime CreatedAt\n{\n    get<\/span> => field;\n    set<\/span>;  \/\/ compiler handles this, field is assigned directly<\/span>\n}\n\n\/\/ Only the setter has logic; getter is auto-generated<\/span>\npublic<\/span> string<\/span> Username\n{\n    get<\/span>;\n    set<\/span> => field = value<\/span>?.Trim() ?? throw<\/span> new<\/span> ArgumentNullException(nameof<\/span>(value<\/span>));\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      That last pattern is particularly useful \u2014 you can leave the getter as a simple auto-accessor and only write the setter when that’s the only side that needs logic, without having to write get => field;<\/code> explicitly.<\/p>\n\n\n\n
      Type Inference<\/h3>\n\n\n\n
      The type of field<\/code> is inferred from the property’s declared type. There’s no ambiguity here and nothing to configure. If the property is declared as decimal Price<\/code>, then field<\/code> is a decimal<\/code>. If the property is List<string> Tags<\/code>, then field<\/code> is a List<string><\/code>. You’re always working with the same type as the property itself.<\/p>\n\n\n\n
      Nullability<\/h3>\n\n\n\n
      Nullability follows the property’s declared type as well, and this is where things get slightly nuanced. Consider a nullable reference type scenario:<\/p>\n\n\n
      public<\/span> string<\/span>? DisplayName\n{\n    get<\/span> => field ?? \"Anonymous\"<\/span>;\n    set<\/span> => field = value<\/span>;\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Here field<\/code> is string?<\/code>, matching the property type. The getter returns a non-nullable string<\/code> by coalescing with a default, but the stored value can genuinely be null. The compiler understands this and won’t raise a nullability warning on the getter’s return path.<\/p>\n\n\n\n
      Where it gets trickier is when the property type is non-nullable but you want lazy initialization \u2014 initializing field<\/code> on first access rather than at construction time:<\/p>\n\n\n
      public<\/span> string<\/span> Description\n{\n    get<\/span> => field ??= LoadDescription();\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The compiler will warn here because field<\/code> is string<\/code> (non-nullable) yet it’s being treated as potentially null through the ??=<\/code> operator. You’d need to declare the property as string?<\/code> and handle the nullability at the call site, or suppress the warning explicitly if you’re confident about the initialization path. This is one of the few places where the feature’s convenience has a minor rough edge.<\/p>\n\n\n\n
      Initializers<\/h3>\n\n\n\n
      You can provide a property initializer the same way you would with an auto-property, and field<\/code> will be pre-populated with that value:<\/p>\n\n\n
      public<\/span> int<\/span> RetryCount\n{\n    get<\/span> => field;\n    set<\/span> => field = Math.Clamp(value<\/span>, 0<\/span>, 10<\/span>);\n} = 3<\/span>;<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The = 3<\/code> at the end initializes the backing field to 3<\/code> before any constructor logic runs, exactly as it would with a plain auto-property. The setter’s clamping logic does not run during initialization \u2014 the value is written directly to field<\/code> \u2014 so if you need invariants enforced even during initialization, you’ll want to handle that in the constructor instead.<\/p>\n\n\n\n
      LangVersion<\/code> Requirement<\/h3>\n\n\n\n
      Semi-auto properties and the field<\/code> keyword require LangVersion<\/code> set to preview<\/code> in C# 13 during the preview period, and will require 13<\/code> or later once the feature ships in a stable release. If you’re targeting an older language version, field<\/code> is simply treated as a regular identifier, and the compiler won’t synthesize a backing field for it. This can lead to confusing errors if you accidentally use field<\/code> in a codebase with a lower LangVersion<\/code> \u2014 worth checking your project file if something seems off.<\/p>\n\n\n\n
      5. Step-by-Step: Migrating Common Patterns to Semi-Auto Properties<\/h2>\n\n\n\n
      This is where the feature earns its keep. Let’s walk through five patterns you’ve almost certainly written before \u2014 each one a case where an auto-property wasn’t enough and a full backing field felt like overkill. For each pattern, we’ll look at the old approach and then the semi-auto equivalent, with notes on what changed and why.<\/p>\n\n\n\n
      \n\n\n\n
      Pattern 1: Validation in Setters<\/h3>\n\n\n\n
      This is the canonical use case, and the one the C# team almost certainly had front of mind when designing the feature.<\/p>\n\n\n\n
      Before:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> Order<\/span>\n{\n    private<\/span> int<\/span> _quantity;\n\n    public<\/span> int<\/span> Quantity\n    {\n        get<\/span> => _quantity;\n        set<\/span>\n        {\n            if<\/span> (value<\/span> <= 0<\/span>)\n                throw<\/span> new<\/span> ArgumentOutOfRangeException(nameof<\/span>(value<\/span>), \"Quantity must be greater than zero.\"<\/span>);\n            _quantity = value<\/span>;\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      After:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> Order<\/span>\n{\n    public<\/span> int<\/span> Quantity\n    {\n        get<\/span>;\n        set<\/span>\n        {\n            if<\/span> (value<\/span> <= 0<\/span>)\n                throw<\/span> new<\/span> ArgumentOutOfRangeException(nameof<\/span>(value<\/span>), \"Quantity must be greater than zero.\"<\/span>);\n            field = value<\/span>;\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The private field is gone. The getter is now an auto-accessor \u2014 you don’t even need to write get => field;<\/code> explicitly. The setter retains all its validation logic and writes to field<\/code> instead of _quantity<\/code>. The compiled output is identical to the before version; the difference is entirely in how much you had to write and maintain.<\/p>\n\n\n\n
      If you have multiple validated properties on the same class, the cumulative reduction in boilerplate is substantial. A class with five validated properties previously meant five private fields declared at the top, five property declarations below them, and the constant discipline of making sure nothing in the class bypassed a property by writing to the field directly. With semi-auto properties, that entire category of concern disappears.<\/p>\n\n\n\n
      \n\n\n\n
      Pattern 2: Lazy Initialization in Getters<\/h3>\n\n\n\n
      Lazy initialization \u2014 computing or loading a value only when it’s first requested and caching it for subsequent accesses \u2014 is another pattern that’s simple in concept but verbose to implement with a full backing field.<\/p>\n\n\n\n
      Before:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> ReportGenerator<\/span>\n{\n    private<\/span> List<string<\/span>>? _sections;\n\n    public<\/span> List<string<\/span>> Sections\n    {\n        get<\/span> => _sections ??= LoadSections();\n    }\n\n    private<\/span> List<string<\/span>> LoadSections<\/span>(<\/span>)<\/span> { \/* ... *\/<\/span> }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      After:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> ReportGenerator<\/span>\n{\n    public<\/span> List<string<\/span>>? Sections\n    {\n        get<\/span> => field ??= LoadSections();\n    }\n\n    private<\/span> List<string<\/span>> LoadSections<\/span>(<\/span>)<\/span> { \/* ... *\/<\/span> }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Notice that the property type has to be List<string>?<\/code> here rather than List<string><\/code>, because field<\/code> starts as null and the nullability analyzer needs to know that’s intentional. This is the nullability edge case mentioned in the previous section. Whether that nullable annotation leaks into your public API depends on how comfortable you are with suppressing the warning or adjusting call sites \u2014 it’s a minor trade-off worth being aware of.<\/p>\n\n\n\n
      That said, for internal properties, private properties, or cases where nullable reference types aren’t enabled, this pattern is a clean win with zero downsides.<\/p>\n\n\n\n
      \n\n\n\n
      Pattern 3: Trimming and Normalizing Input<\/h3>\n\n\n\n
      String properties frequently need light sanitization on the way in \u2014 trimming whitespace, normalizing casing, collapsing empty strings to null. This is almost never worth a full backing field, but it’s always been just out of reach for auto-properties.<\/p>\n\n\n\n
      Before:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> UserProfile<\/span>\n{\n    private<\/span> string<\/span>? _displayName;\n\n    public<\/span> string<\/span>? DisplayName\n    {\n        get<\/span> => _displayName;\n        set<\/span> => _displayName = value<\/span>?.Trim();\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      After:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> UserProfile<\/span>\n{\n    public<\/span> string<\/span>? DisplayName\n    {\n        get<\/span>;\n        set<\/span> => field = value<\/span>?.Trim();\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Short, obvious, and self-contained. The getter needs no custom logic so it stays as an auto-accessor. The setter does its one job. Anyone reading this class knows exactly what DisplayName<\/code> does with assigned values without needing to scroll up to find a backing field declaration.<\/p>\n\n\n\n
      This pattern scales nicely. You might have a UserProfile<\/code> with six string properties that all need trimming. Previously that meant six backing fields. Now it’s six properties with a one-line setter each and nothing else.<\/p>\n\n\n\n
      \n\n\n\n
      Pattern 4: Computed Caching<\/h3>\n\n\n\n
      Sometimes a property’s value is expensive to compute \u2014 it might involve LINQ aggregation, string building, or any other non-trivial operation \u2014 but the inputs don’t change often enough to justify recomputing on every access. The classic solution is a nullable backing field used as a cache, cleared whenever the underlying data changes.<\/p>\n\n\n\n
      Before:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> Invoice<\/span>\n{\n    private<\/span> decimal<\/span>? _total;\n    private<\/span> List<LineItem> _lineItems = new<\/span>();\n\n    public<\/span> List<LineItem> LineItems\n    {\n        get<\/span> => _lineItems;\n        set<\/span>\n        {\n            _lineItems = value<\/span>;\n            _total = null<\/span>; \/\/ invalidate cache<\/span>\n        }\n    }\n\n    public<\/span> decimal<\/span> Total\n    {\n        get<\/span> => _total ??= _lineItems.Sum(x => x.Amount);\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      After:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> Invoice<\/span>\n{\n    public<\/span> List<LineItem> LineItems\n    {\n        get<\/span>;\n        set<\/span>\n        {\n            field = value<\/span>;\n            Total = null<\/span>; \/\/ invalidate cache<\/span>\n        }\n    } = new<\/span>();\n\n    public<\/span> decimal<\/span>? Total\n    {\n        get<\/span> => field ??= LineItems.Sum(x => x.Amount);\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Both LineItems<\/code> and Total<\/code> are now semi-auto properties. LineItems<\/code> uses an initializer (= new()<\/code>) to set the default value, and its setter invalidates the Total<\/code> cache by setting it to null directly \u2014 which is valid because Total<\/code> is declared as decimal?<\/code>. The cache-and-compute logic in Total<\/code>‘s getter is unchanged in behavior but no longer requires a separately declared _total<\/code> field.<\/p>\n\n\n\n
      One thing to note: setting Total = null<\/code> from within LineItems<\/code>‘ setter assigns directly to Total<\/code>‘s backing field only if Total<\/code> has no setter of its own with custom logic. Since Total<\/code> has only a getter here, the assignment Total = null<\/code> won’t compile \u2014 you’d still need either a setter on Total<\/code> or a separate backing field for this specific invalidation pattern. This is a case where semi-auto properties get you most of the way but a full backing field still makes sense for the cache field specifically. It’s a good example of the feature not being a universal replacement.<\/p>\n\n\n\n
      \n\n\n\n
      Pattern 5: Init-Only Properties with Transformation<\/h3>\n\n\n\n
      Since C# 9, init<\/code> accessors have allowed properties to be set during object initialization but made immutable afterward. Semi-auto properties work naturally with init<\/code>, and the combination is particularly useful when you want to transform or validate a value at construction time.<\/p>\n\n\n\n
      Before:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> Ticket<\/span>\n{\n    private<\/span> string<\/span> _reference;\n\n    public<\/span> string<\/span> Reference\n    {\n        get<\/span> => _reference;\n        init\n        {\n            if<\/span> (string<\/span>.IsNullOrWhiteSpace(value<\/span>))\n                throw<\/span> new<\/span> ArgumentException(\"Reference cannot be blank.\"<\/span>, nameof<\/span>(value<\/span>));\n            _reference = value<\/span>.ToUpperInvariant();\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      After:<\/strong><\/p>\n\n\n
      public<\/span> class<\/span> Ticket<\/span>\n{\n    public<\/span> string<\/span> Reference\n    {\n        get<\/span>;\n        init\n        {\n            if<\/span> (string<\/span>.IsNullOrWhiteSpace(value<\/span>))\n                throw<\/span> new<\/span> ArgumentException(\"Reference cannot be blank.\"<\/span>, nameof<\/span>(value<\/span>));\n            field = value<\/span>.ToUpperInvariant();\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Clean and immutable. The init<\/code> accessor runs once during object initialization \u2014 via a constructor, an object initializer, or a with<\/code> expression on a record \u2014 validates the input, normalizes it to uppercase, and writes it to field<\/code>. After that, the backing field is frozen and Reference<\/code> becomes effectively read-only for the lifetime of the object.<\/p>\n\n\n\n
      Combine this with the required<\/code> modifier introduced in C# 11 and you have a tight, expressive pattern for value objects and domain entities:<\/p>\n\n\n
      public<\/span> class<\/span> Ticket<\/span>\n{\n    public<\/span> required string<\/span> Reference\n    {\n        get<\/span>;\n        init\n        {\n            if<\/span> (string<\/span>.IsNullOrWhiteSpace(value<\/span>))\n                throw<\/span> new<\/span> ArgumentException(\"Reference cannot be blank.\"<\/span>, nameof<\/span>(value<\/span>));\n            field = value<\/span>.ToUpperInvariant();\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Now Reference<\/code> must be set during initialization, will be validated and normalized when it is, and can never be changed afterward. That’s a lot of correctness guarantees for very little code.<\/p>\n\n\n\n
      6. Using field<\/code> with get<\/code>-Only and init<\/code> Accessors<\/h2>\n\n\n\n
      Read-only properties are one of the more underappreciated tools in C#. They communicate intent clearly \u2014 this value is set once and doesn’t change \u2014 and they make types easier to reason about, especially in concurrent or functional-style code. Semi-auto properties work well in this space, but there are a few behavioral specifics worth understanding before you rely on them.<\/p>\n\n\n\n
      Get-Only Semi-Auto Properties<\/h3>\n\n\n\n
      A get-only auto-property looks like this:<\/p>\n\n\n
      public<\/span> string<\/span> Id { get<\/span>; }<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The compiler generates a read-only backing field for it, and the only place that field can be assigned is in the constructor or via a field initializer. That rule carries over to get-only semi-auto properties:<\/p>\n\n\n
      public<\/span> string<\/span> Id\n{\n    get<\/span> => field.ToUpperInvariant();\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This compiles. The backing field for Id<\/code> is still read-only \u2014 it can only be assigned in the constructor or via an initializer \u2014 and the getter applies a transformation on the way out. You’re not storing the uppercased value; you’re storing whatever was assigned in the constructor and uppercasing it on every read. Whether that’s what you want depends on the situation, but it’s a valid and useful pattern for lightweight formatting that doesn’t warrant caching.<\/p>\n\n\n\n
      Here’s what constructor assignment looks like with a get-only semi-auto property:<\/p>\n\n\n
      public<\/span> class<\/span> Event<\/span>\n{\n    public<\/span> string<\/span> Name\n    {\n        get<\/span> => field.Trim();\n    }\n\n    public<\/span> Event<\/span>(string<\/span> name<\/span>)<\/span>\n    {\n        Name = name; \/\/ assigns directly to the backing field<\/span>\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Notice that the constructor assigns to Name<\/code>, not to a backing field named _name<\/code>. The compiler allows this for get-only properties within the constructor body, exactly as it does for get-only auto-properties. The assignment bypasses the getter \u2014 it goes straight to the synthesized backing field \u2014 so the trimming in the getter has no effect at assignment time. It only runs when the property is read.<\/p>\n\n\n\n
      This is an important behavioral detail: accessor logic only runs when the accessor runs<\/strong>. An assignment in a constructor goes directly to field<\/code>, not through any setter you may or may not have defined. If you need your normalization or validation logic to run at construction time too, you need to either apply it explicitly in the constructor or use an init<\/code> accessor instead.<\/p>\n\n\n\n
      Get-Only with Field Initializers<\/h3>\n\n\n\n
      You can combine a get-only semi-auto property with a field initializer just as you would with an auto-property:<\/p>\n\n\n
      public<\/span> class<\/span> Session<\/span>\n{\n    public<\/span> Guid SessionId\n    {\n        get<\/span> => field;\n    } = Guid.NewGuid();\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The initializer runs before the constructor body, pre-populating field<\/code> with a new Guid<\/code>. The property is read-only from that point on. This is functionally identical to public Guid SessionId { get; } = Guid.NewGuid();<\/code> except that you now have the option to add getter logic around field<\/code> if you ever need to. In this particular example the getter is trivial, but it’s easy to imagine adding formatting or transformation later without having to restructure the property.<\/p>\n\n\n\n
      init<\/code> Accessors and field<\/code><\/h3>\n\n\n\n
      We touched on init<\/code> in the previous section, but it’s worth going deeper here because the interaction between init<\/code> and field<\/code> has a few nuances that matter in practice.<\/p>\n\n\n\n
      An init<\/code> accessor behaves like a set<\/code> accessor during object initialization and like no accessor at all afterward. From the compiler’s perspective, field<\/code> inside an init<\/code> accessor is writable during the initialization phase and then implicitly read-only once the object is fully constructed. This means you get the same guarantees as a get-only property \u2014 immutability after construction \u2014 but with the ability to set the value via object initializer syntax rather than only through a constructor.<\/p>\n\n\n
      public<\/span> class<\/span> Address<\/span>\n{\n    public<\/span> string<\/span> Street\n    {\n        get<\/span>;\n        init => field = value<\/span>.Trim();\n    }\n\n    public<\/span> string<\/span> City\n    {\n        get<\/span>;\n        init => field = value<\/span>.Trim();\n    }\n}\n\n\/\/ Usage:<\/span>\nvar<\/span> address = new<\/span> Address\n{\n    Street = \"  123 Main St  \"<\/span>,\n    City = \"  Springfield  \"<\/span>\n};\n\nConsole.WriteLine(address.Street); \/\/ \"123 Main St\"<\/span>\nConsole.WriteLine(address.City);   \/\/ \"Springfield\"<\/span><\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The trimming happens in the init<\/code> accessor when the object is initialized, and the cleaned values are what get stored in field<\/code>. After that, neither Street<\/code> nor City<\/code> can be reassigned.<\/p>\n\n\n\n
      Combining get<\/code> and init<\/code> with Separate Logic<\/h3>\n\n\n\n
      One pattern that becomes genuinely expressive with semi-auto properties is having distinct logic in both the get<\/code> and init<\/code> accessors:<\/p>\n\n\n
      public<\/span> class<\/span> Product<\/span>\n{\n    public<\/span> string<\/span> Sku\n    {\n        get<\/span> => field.ToUpperInvariant();\n        init\n        {\n            if<\/span> (string<\/span>.IsNullOrWhiteSpace(value<\/span>))\n                throw<\/span> new<\/span> ArgumentException(\"SKU cannot be blank.\"<\/span>, nameof<\/span>(value<\/span>));\n            field = value<\/span>.Trim();\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Here the init<\/code> accessor validates and trims the input before storing it, and the get<\/code> accessor uppercases on every read. You’re storing a trimmed-but-original-case value and presenting it as uppercase. Whether you’d prefer to store it uppercase and present it as-is is a design decision \u2014 the point is that field<\/code> gives you independent control over what gets stored and what gets returned, without any separately declared backing field.<\/p>\n\n\n\n
      required<\/code> and init<\/code> Together<\/h3>\n\n\n\n
      Combining required<\/code> with an init<\/code> semi-auto property gives you a pattern that enforces construction-time assignment, validates the input, and guarantees immutability \u2014 all in one property declaration:<\/p>\n\n\n
      public<\/span> class<\/span> Customer<\/span>\n{\n    public<\/span> required string<\/span> Email\n    {\n        get<\/span>;\n        init\n        {\n            if<\/span> (!value<\/span>.Contains('@'<\/span>))\n                throw<\/span> new<\/span> ArgumentException(\"Invalid email address.\"<\/span>, nameof<\/span>(value<\/span>));\n            field = value<\/span>.ToLowerInvariant();\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The required<\/code> modifier means the compiler will enforce that Email<\/code> is set in any object initializer that constructs a Customer<\/code>. The init<\/code> accessor validates and normalizes the value when it’s set. And once construction is complete, Email<\/code> is frozen. You get compiler enforcement, runtime validation, and immutability, and the whole thing fits in eight lines with no separate backing field.<\/p>\n\n\n\n
      This combination \u2014 required<\/code>, init<\/code>, and field<\/code> \u2014 is probably the most practically useful pattern the feature enables for anyone building domain models, DTOs, or value objects. It’s worth having in your toolkit.<\/p>\n\n\n\n
      7. Attribute Targeting: Applying Attributes to the Synthesized Backing Field<\/h2>\n\n\n\n
      One of the quieter pain points with auto-properties has always been attributes. Specifically: what do you do when you need to apply an attribute to the backing field rather than the property itself?<\/p>\n\n\n\n
      With a full property and an explicit backing field, this is trivial \u2014 you just decorate the field directly. With an auto-property, the backing field is compiler-generated and invisible, so you have to use the field:<\/code> attribute target to reach it:<\/p>\n\n\n
      [field: NonSerialized<\/span>]\npublic<\/span> int<\/span> CachedValue { get<\/span>; set<\/span>; }<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This syntax has existed since C# was young, but it’s always felt a little awkward because it requires you to know that the compiler generated a field, know its target specifier, and trust that the attribute will land in the right place. More importantly, it only works for auto-properties \u2014 the moment you converted to a full property with an explicit backing field, you’d go back to decorating the field directly and the field:<\/code> target syntax became irrelevant.<\/p>\n\n\n\n
      Semi-auto properties change this. Because the backing field is still compiler-generated even when you write custom accessor logic, the field:<\/code> attribute target remains the correct and only way to decorate it. This actually makes the attribute story for semi-auto properties more consistent than it’s ever been for auto-properties, because now the same syntax works across a much broader range of property shapes.<\/p>\n\n\n\n
      The field:<\/code> Target Specifier<\/h3>\n\n\n\n
      The syntax is the same as it was for auto-properties:<\/p>\n\n\n
      public<\/span> class<\/span> UserSession<\/span>\n{\n    [field: NonSerialized<\/span>]\n    public<\/span> DateTime LastAccessed\n    {\n        get<\/span>;\n        set<\/span> => field = value<\/span>;\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The [field: NonSerialized]<\/code> attribute is applied to the synthesized backing field, not to the property itself. The property remains visible and serializable as far as property-level serialization is concerned \u2014 it’s specifically the field that gets the attribute. This distinction matters depending on which serialization mechanism you’re using and whether it inspects fields, properties, or both.<\/p>\n\n\n\n
      Common Use Cases<\/h3>\n\n\n\n
      JSON serialization with System.Text.Json<\/code> or Newtonsoft.Json<\/strong><\/p>\n\n\n\n
      If you’re using a serializer that can be configured to serialize fields as well as properties, you may want to exclude the backing field explicitly to avoid double-serialization:<\/p>\n\n\n
      public<\/span> class<\/span> ApiResponse<\/span>\n{\n    [field: System.Text.Json.Serialization.JsonIgnore<\/span>]\n    public<\/span> string<\/span> RawPayload\n    {\n        get<\/span> => field;\n        set<\/span> => field = value<\/span>?.Trim();\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      In most System.Text.Json<\/code> configurations you won’t need this because field serialization is opt-in, but in Newtonsoft.Json with MemberSerialization.Fields<\/code> or similar settings, it becomes relevant.<\/p>\n\n\n\n
      Debugger visibility<\/strong><\/p>\n\n\n\n
      The synthesized backing field will show up in the debugger’s locals and watch windows under a compiler-generated name \u2014 something like <RawPayload>k__BackingField<\/code>. If you’re debugging a type with several semi-auto properties and the backing fields are cluttering your watch window, you can suppress them:<\/p>\n\n\n
      public<\/span> class<\/span> ViewModel<\/span>\n{\n    [field: System.Diagnostics.DebuggerBrowsable(System.Diagnostics.DebuggerBrowsableState.Never)<\/span>]\n    public<\/span> string<\/span> Title\n    {\n        get<\/span> => field ?? \"Untitled\"<\/span>;\n        set<\/span> => field = value<\/span>;\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This is the same technique used by auto-property backing fields internally \u2014 the compiler applies DebuggerBrowsable(Never)<\/code> to its generated fields automatically. With semi-auto properties, it doesn’t do this by default, so if debugger cleanliness matters to you, you can apply it manually.<\/p>\n\n\n\n
      ThreadStatic<\/code> and SkipLocalsInit<\/code><\/strong><\/p>\n\n\n\n
      For more advanced scenarios, you can apply attributes like [field: ThreadStatic]<\/code> to make the backing field thread-local, though this is an unusual pattern for a property and you should be deliberate about it. Similarly, [field: SkipLocalsInit]<\/code> is technically applicable but unlikely to be meaningful in practice for most property patterns.<\/p>\n\n\n\n
      What You Cannot Do<\/h3>\n\n\n\n
      The field:<\/code> target only applies to the synthesized backing field. You cannot use it to apply attributes to the property’s getter or setter \u2014 those have their own target specifiers (get:<\/code> and set:<\/code> or return:<\/code> for the getter’s return value, though these are rarely used in practice). Mixing up these targets is a compile-time error, so the compiler will catch it early.<\/p>\n\n\n\n
      It’s also worth noting that the field:<\/code> target only works when there is a synthesized backing field to target \u2014 meaning the property must be an auto-property or a semi-auto property. Applying [field: ...]<\/code> to a computed property with no field<\/code> reference and no auto-accessor will produce a compiler warning or error depending on the context, because there’s no backing field for the attribute to land on.<\/p>\n\n\n\n
      A Practical Recommendation<\/h3>\n\n\n\n
      If you’re migrating auto-properties to semi-auto properties and those auto-properties already had [field: ...]<\/code> attributes on them, the good news is that your attribute declarations don’t need to change at all. The field:<\/code> target specifier works identically on both. The migration is purely a matter of adding accessor logic and switching from implicit get<\/code>\/set<\/code> to explicit bodies \u2014 the attribute targeting layer is completely unaffected.<\/p>\n\n\n\n
      8. field<\/code> in Structs, Records, and Record Structs<\/h2>\n\n\n\n
      So far all of our examples have used classes, which is where most developers will reach for semi-auto properties first. But field<\/code> works across all type kinds in C#, and each one has its own behavioral nuances worth understanding before you use the feature in a struct or record context.<\/p>\n\n\n\n
      Structs<\/h3>\n\n\n\n
      Structs have always had a slightly awkward relationship with properties. Before C# 10, a struct couldn’t even have auto-properties with custom logic in certain contexts without running into definite assignment issues. Things have improved considerably since then, but structs still carry rules that classes don’t, and semi-auto properties surface a couple of them.<\/p>\n\n\n\n
      The most important rule: structs are value types, and mutation through a property on a copied struct won’t affect the original<\/strong>. This isn’t specific to semi-auto properties \u2014 it’s a fundamental struct behavior \u2014 but it’s worth stating explicitly because field<\/code> can make property-based mutation look deceptively clean:<\/p>\n\n\n
      public<\/span> struct<\/span> Temperature\n{\n    public<\/span> double<\/span> Celsius\n    {\n        get<\/span> => field;\n        set<\/span> => field = Math.Round(value<\/span>, 2<\/span>);\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This works exactly as you’d expect when you’re working with a direct reference to the struct. Where it bites you is in scenarios like this:<\/p>\n\n\n
      Temperature[] readings = new<\/span> Temperature[5<\/span>];\nreadings[0<\/span>].Celsius = 98.6<\/span>; \/\/ fine, modifies array element directly<\/span>\n\nTemperature t = readings[0<\/span>];\nt.Celsius = 100.0<\/span>; \/\/ modifies the copy, not readings[0]<\/span><\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Nothing about this behavior is new or specific to field<\/code> \u2014 it’s how structs have always worked. But because semi-auto properties make property logic look so lightweight and clean, it’s easy to forget you’re working with a value type and accidentally mutate a copy. Keep your usual struct discipline in place.<\/p>\n\n\n\n
      Definite assignment in structs<\/strong> is the other area to watch. In a struct, the compiler requires that all fields be definitely assigned before the constructor completes. With auto-properties, the compiler could reason about this easily because it knew the property and its backing field were in a one-to-one relationship. With semi-auto properties, the same relationship holds \u2014 assigning to a semi-auto property in a constructor assigns directly to the synthesized backing field \u2014 so definite assignment works as expected:<\/p>\n\n\n
      public<\/span> struct<\/span> Point\n{\n    public<\/span> double<\/span> X\n    {\n        get<\/span> => field;\n        set<\/span> => field = value<\/span>;\n    }\n\n    public<\/span> double<\/span> Y\n    {\n        get<\/span> => field;\n        set<\/span> => field = value<\/span>;\n    }\n\n    public<\/span> Point<\/span>(double<\/span> x, double<\/span> y<\/span>)<\/span>\n    {\n        X = x; \/\/ assigns to backing field for X<\/span>\n        Y = y; \/\/ assigns to backing field for Y<\/span>\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The compiler is satisfied that both backing fields are assigned in the constructor. If you forget to assign one, you’ll get the same definite assignment error you’d get with an explicit backing field.<\/p>\n\n\n\n
      Readonly structs<\/strong> add another layer. In a readonly struct<\/code>, all fields must be read-only, which means a semi-auto property in a readonly struct can only have a get<\/code> accessor or an init<\/code> accessor \u2014 not a mutable set<\/code>. Attempting to write a set<\/code> accessor that assigns to field<\/code> in a readonly struct will produce a compiler error, because the synthesized backing field would need to be mutable to support it, which contradicts the readonly<\/code> declaration:<\/p>\n\n\n
      public<\/span> readonly<\/span> struct<\/span> ImmutablePoint\n{\n    public<\/span> double<\/span> X\n    {\n        get<\/span> => field; \/\/ fine<\/span>\n        init => field = value<\/span>; \/\/ fine<\/span>\n        \/\/ set => field = value; \/\/ compiler error<\/span>\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This is consistent with how full properties work in readonly structs and shouldn’t be surprising, but it’s good to have it explicit.<\/p>\n\n\n\n
      Records<\/h3>\n\n\n\n
      Records are where things get interesting, because the C# compiler generates a significant amount of code on your behalf for records \u2014 equality members, GetHashCode<\/code>, ToString<\/code> via PrintMembers<\/code>, and for positional records, a deconstructor as well. Semi-auto properties interact with all of this generated code, and the interaction is largely seamless, but there are details worth knowing.<\/p>\n\n\n\n
      Equality and GetHashCode<\/code><\/strong> in records are generated based on the properties of the record, not its fields. This is an important distinction. The compiler-generated Equals<\/code> and GetHashCode<\/code> for a record call the property getters to get the values to compare and hash. That means if your semi-auto property’s getter applies a transformation \u2014 say, trimming or uppercasing \u2014 the equality comparison will use the transformed value, not whatever raw value is stored in field<\/code>:<\/p>\n\n\n
      public<\/span> record Person\n{\n    public<\/span> required string<\/span> Name\n    {\n        get<\/span> => field.Trim();\n        init => field = value<\/span>;\n    }\n}\n\nvar<\/span> a = new<\/span> Person { Name = \"Alice\"<\/span> };\nvar<\/span> b = new<\/span> Person { Name = \"Alice  \"<\/span> }; \/\/ trailing spaces<\/span>\n\nConsole.WriteLine(a == b); \/\/ true \u2014 both getters return \"Alice\"<\/span><\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This might be exactly what you want \u2014 equality based on the normalized, meaningful value rather than the raw stored one. Or it might surprise you if you weren’t thinking about it. Either way, be deliberate: when you add getter logic to a record property, you’re also changing what equality means for that record.<\/p>\n\n\n\n
      PrintMembers<\/code> and ToString<\/code><\/strong> follow the same rule. The generated ToString<\/code> for a record calls property getters, so the output will reflect your getter transformation rather than the raw stored value. For debugging and logging purposes this is usually the right behavior, but again, worth being conscious of.<\/p>\n\n\n\n
      with<\/code> expressions<\/strong> are the one area where the interaction requires more care. A with<\/code> expression creates a copy of a record with specified properties changed. Under the hood, the compiler uses the property’s init<\/code> accessor (or setter, for mutable records) to apply the changed values to the copy. This means your init<\/code> logic \u2014 validation, normalization, whatever you’ve put in there \u2014 runs again during a with<\/code> expression:<\/p>\n\n\n
      public<\/span> record Product\n{\n    public<\/span> required string<\/span> Name\n    {\n        get<\/span>;\n        init\n        {\n            if<\/span> (string<\/span>.IsNullOrWhiteSpace(value<\/span>))\n                throw<\/span> new<\/span> ArgumentException(\"Name cannot be blank.\"<\/span>);\n            field = value<\/span>.Trim();\n        }\n    }\n}\n\nvar<\/span> original = new<\/span> Product { Name = \"Widget\"<\/span> };\nvar<\/span> renamed = original with { Name = \"  Gadget  \"<\/span> }; \/\/ init runs, trims to \"Gadget\"<\/span>\nvar<\/span> invalid = original with { Name = \"\"<\/span> }; \/\/ throws ArgumentException<\/span><\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This is generally the correct behavior \u2014 you want your invariants enforced on with<\/code> just as they are on initial construction. But if your init<\/code> accessor has side effects beyond simple validation and normalization, be aware that with<\/code> will trigger them.<\/p>\n\n\n\n
      Positional Records<\/h3>\n\n\n\n
      Positional record properties are auto-generated by the compiler from the primary constructor parameters:<\/p>\n\n\n
      public<\/span> record Point<\/span>(double<\/span> X, double<\/span> Y<\/span>)<\/span>;<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      These generated properties are standard auto-properties. You cannot directly attach field<\/code>-based accessor logic to a positional property inline in the primary constructor syntax. If you need a positional record property to have semi-auto behavior, you need to override it explicitly in the record body:<\/p>\n\n\n
      public<\/span> record Point<\/span>(double<\/span> X, double<\/span> Y<\/span>)<\/span>\n{\n    public<\/span> double<\/span> X\n    {\n        get<\/span> => field;\n        init => field = Math.Round(value<\/span>, 4<\/span>);\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This overrides the compiler-generated X<\/code> property with your semi-auto version. The positional deconstructor still works \u2014 it calls the property getter, which returns field<\/code> \u2014 and equality and ToString<\/code> use the getter as well, so the rounded value is what participates in all record-generated behavior. The Y<\/code> property remains a plain auto-property since you didn’t override it.<\/p>\n\n\n\n
      Record Structs<\/h3>\n\n\n\n
      Record structs, introduced in C# 10, combine the value-type semantics of structs with the equality and ToString<\/code> generation of records. Semi-auto properties in record structs follow both sets of rules discussed above: value-type mutation semantics apply, readonly record structs prohibit mutable setters, and record-generated equality calls property getters.<\/p>\n\n\n
      public<\/span> readonly<\/span> record struct<\/span> Coordinate\n{\n    public<\/span> double<\/span> Latitude\n    {\n        get<\/span> => field;\n        init => field = Math.Clamp(value<\/span>, -90<\/span>, 90<\/span>);\n    }\n\n    public<\/span> double<\/span> Longitude\n    {\n        get<\/span> => field;\n        init => field = Math.Clamp(value<\/span>, -180<\/span>, 180<\/span>);\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This is a clean and expressive pattern for small, immutable value objects. The clamping in the init<\/code> accessors enforces geographic validity at construction time, the record generates correct equality and hashing based on the clamped values, and the readonly<\/code> modifier on the record struct ensures nobody accidentally mutates a copy and wonders why the original didn’t change. It’s a good illustration of how several C# features layer together naturally once you understand what each one contributes.<\/p>\n\n\n\n
      9. Thread Safety Considerations<\/h2>\n\n\n\n
      Thread safety and properties have always had an uneasy relationship in C#. Auto-properties gave developers a convenient way to expose state, but they never made any promises about concurrent access \u2014 and semi-auto properties don’t change that. Before reaching for field<\/code> in a multithreaded context, it’s worth being clear about what the feature does and doesn’t give you.<\/p>\n\n\n\n
      What field<\/code> Doesn’t Change<\/h3>\n\n\n\n
      The synthesized backing field created by the compiler for a semi-auto property is a plain instance field. It gets no special treatment in terms of memory visibility, atomicity, or ordering. Concurrent reads and writes to it carry exactly the same risks as concurrent reads and writes to any other unsynchronized field \u2014 torn reads on types larger than the native word size, stale values due to CPU caching, and race conditions when your accessor logic involves more than a single memory operation.<\/p>\n\n\n\n
      This is not a criticism of the feature. Thread safety is a cross-cutting concern that C# has deliberately left to developers and synchronization primitives rather than baking into the language’s property model. The point is simply that field<\/code> doesn’t add anything new here, and you shouldn’t expect it to.<\/p>\n\n\n\n
      Consider this seemingly harmless semi-auto property:<\/p>\n\n\n
      public<\/span> class<\/span> RequestCounter<\/span>\n{\n    public<\/span> int<\/span> Count\n    {\n        get<\/span> => field;\n        set<\/span> => field = value<\/span>;\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      If multiple threads are incrementing Count<\/code> via counter.Count++<\/code>, you have a race condition. The increment operation is not atomic \u2014 it’s a read, an increment, and a write \u2014 and the fact that it happens through a semi-auto property rather than a plain field makes no difference whatsoever. The same issue exists with a full property backed by an explicit field, and with a plain public field.<\/p>\n\n\n\n
      Lazy Initialization and Thread Safety<\/h3>\n\n\n\n
      Lazy initialization is where thread safety concerns become most relevant for semi-auto properties, because the ??=<\/code> pattern discussed in section 5 is not thread-safe:<\/p>\n\n\n
      public<\/span> class<\/span> ReportGenerator<\/span>\n{\n    public<\/span> List<string<\/span>>? Sections\n    {\n        get<\/span> => field ??= LoadSections();\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      If two threads call the Sections<\/code> getter simultaneously and field<\/code> is null for both of them, both will call LoadSections()<\/code>. Whether that’s a problem depends on whether LoadSections<\/code> has side effects and whether having two instances of the result floating around matters. In many cases \u2014 particularly for pure computation with no side effects \u2014 this kind of benign double-initialization is acceptable. But if LoadSections<\/code> hits a database, fires an HTTP request, or has any observable side effect, you need a proper synchronization strategy.<\/p>\n\n\n\n
      The standard solution for thread-safe lazy initialization in C# is Lazy<T><\/code>, and it pairs naturally with semi-auto properties:<\/p>\n\n\n
      public<\/span> class<\/span> ReportGenerator<\/span>\n{\n    public<\/span> Lazy<List<string<\/span>>> Sections\n    {\n        get<\/span>;\n    } = new<\/span> Lazy<List<string<\/span>>>(LoadSections, LazyThreadSafetyMode.ExecutionAndPublication);\n\n    private<\/span> static<\/span> List<string<\/span>> LoadSections<\/span>(<\/span>)<\/span> { \/* ... *\/<\/span> }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This guarantees that LoadSections<\/code> is called exactly once regardless of how many threads race to access Sections<\/code> for the first time. The trade-off is that the property type is now Lazy<List<string>><\/code> rather than List<string><\/code>, so callers write generator.Sections.Value<\/code> instead of generator.Sections<\/code>. Whether that’s acceptable depends on your API design priorities.<\/p>\n\n\n\n
      If you want to hide the Lazy<T><\/code> from callers, a full property with an explicit Lazy<T><\/code> backing field is still the right tool:<\/p>\n\n\n
      public<\/span> class<\/span> ReportGenerator<\/span>\n{\n    private<\/span> readonly<\/span> Lazy<List<string<\/span>>> _sections = \n        new<\/span> Lazy<List<string<\/span>>>(LoadSections, LazyThreadSafetyMode.ExecutionAndPublication);\n\n    public<\/span> List<string<\/span>> Sections => _sections.Value;\n\n    private<\/span> static<\/span> List<string<\/span>> LoadSections<\/span>(<\/span>)<\/span> { \/* ... *\/<\/span> }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This is one of those cases where a semi-auto property genuinely doesn’t help \u2014 the explicit backing field isn’t boilerplate here, it’s load-bearing infrastructure. Recognizing when field<\/code> adds value and when a named backing field is still the right choice is part of using the feature well.<\/p>\n\n\n\n
      Volatile and Interlocked<\/h3>\n\n\n\n
      For simple scalar values where you need visibility guarantees across threads, volatile<\/code> is the traditional answer. With an explicit backing field you can mark it volatile<\/code> directly:<\/p>\n\n\n
      private<\/span> volatile<\/span> bool<\/span> _isRunning;\npublic<\/span> bool<\/span> IsRunning => _isRunning;<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      With a semi-auto property, you can’t apply volatile<\/code> to the synthesized backing field because volatile<\/code> is not an attribute \u2014 it’s a field modifier, and field modifiers aren’t expressible through the [field: ...]<\/code> attribute target syntax. This means that for any property where you need volatile<\/code> semantics on the backing field, you need a full property with an explicit backing field. It’s a genuine limitation of the feature in multithreaded contexts.<\/p>\n\n\n\n
      For atomic integer operations, Interlocked<\/code> works at the level of the field reference, which isn’t accessible from outside the property body. You can use Interlocked<\/code> operations inside an accessor:<\/p>\n\n\n
      public<\/span> class<\/span> RequestCounter<\/span>\n{\n    public<\/span> int<\/span> Count\n    {\n        get<\/span> => field;\n    }\n\n    public<\/span> void<\/span> Increment<\/span>(<\/span>)<\/span> => Interlocked.Increment(ref<\/span> field); \/\/ not valid<\/span>\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This won’t work \u2014 field<\/code> is only accessible inside property accessor bodies, not in methods. For Interlocked<\/code>-based patterns you again need an explicit backing field. This is by design: field<\/code> is intentionally scoped to accessors, and exposing the backing field reference to the broader class body would undermine the encapsulation the feature is meant to enforce.<\/p>\n\n\n\n
      A Practical Decision Framework<\/h3>\n\n\n\n
      The thread safety question for semi-auto properties comes down to a simple set of cases:<\/p>\n\n\n\n
      If the property is read-only after construction and written only during initialization \u2014 which covers most immutable types, DTOs, and value objects \u2014 thread safety is a non-issue. Reads after construction are safe without synchronization as long as there’s a happens-before relationship between the write and the first read, which constructors and object initializers provide.<\/p>\n\n\n\n
      If the property is mutable and accessed from multiple threads, and all you need is visibility rather than atomicity, you need volatile<\/code> on the backing field \u2014 which means a full property with an explicit field.<\/p>\n\n\n\n
      If you need atomic operations or lazy initialization with strong thread safety guarantees, Interlocked<\/code> and Lazy<T><\/code> respectively are the right tools, and both require explicit backing fields to use properly with properties.<\/p>\n\n\n\n
      If the property is mutable and accessed from multiple threads and you’re using locks, the lock lives outside the property anyway, which means the property itself doesn’t need to do anything special \u2014 semi-auto or full, it makes no difference.<\/p>\n\n\n\n
      The pattern that semi-auto properties handle well in concurrent code is the one that needs no special handling at all: immutable-after-construction state, set via init<\/code> or in a constructor, read freely afterward. For everything else, the existing tools still apply, and the cases where those tools require an explicit backing field are real limitations worth being upfront about.<\/p>\n\n\n\n
      10. Gotchas, Limitations, and Known Edge Cases<\/h2>\n\n\n\n
      Every language feature has its rough edges, and field<\/code> is no exception. Most of the gotchas here are predictable once you understand the design constraints the C# team was working within, but a few are genuinely subtle and worth calling out explicitly so they don’t bite you in production code or a code review.<\/p>\n\n\n\n
      The Name Shadowing Problem<\/h3>\n\n\n\n
      This is the most commonly cited gotcha, and it’s a direct consequence of field<\/code> being a contextual rather than reserved keyword.<\/p>\n\n\n\n
      If you have a parameter or local variable named field<\/code> inside a property accessor, it shadows the keyword. The compiler will prefer the local identifier over the contextual keyword, meaning field<\/code> no longer refers to the synthesized backing field \u2014 it refers to your variable:<\/p>\n\n\n
      public<\/span> class<\/span> Mapper<\/span>\n{\n    public<\/span> string<\/span> Value\n    {\n        get<\/span>;\n        set<\/span>\n        {\n            var<\/span> field = value<\/span>.Trim(); \/\/ local variable named 'field'<\/span>\n            field = field;            \/\/ assigns local to itself, not to backing field!<\/span>\n        }\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      This compiles without error, but it’s almost certainly not what you meant. The backing field never gets assigned, and Value<\/code> will always return the default value for its type. The compiler does emit a warning when a local variable named field<\/code> shadows the keyword inside an accessor, so you’ll be alerted \u2014 but warnings are easy to miss, especially in large codebases where warning counts are already high.<\/p>\n\n\n\n
      The fix is simple: rename the local variable to something that doesn’t conflict. But the real lesson is to treat field<\/code> as mentally reserved inside property accessors, even though the language doesn’t enforce it. If your team adopts semi-auto properties widely, it’s worth adding a linting rule or code review note to flag local variables named field<\/code> inside accessor bodies.<\/p>\n\n\n\n
      This shadowing issue also applies to method parameters in expression-bodied accessors, though that scenario is less common since accessors don’t take parameters directly \u2014 value<\/code> is the implicit parameter in setters and init<\/code> accessors, and field<\/code> isn’t a parameter name you’d reach for naturally in most cases.<\/p>\n\n\n\n
      The Compiler-Generated Field Name<\/h3>\n\n\n\n
      When the compiler synthesizes a backing field for a semi-auto property, it gives that field a name following the same convention used for auto-property backing fields: <PropertyName>k__BackingField<\/code>. So for a property named Price<\/code>, the synthesized field will be named <Price>k__BackingField<\/code> at the IL level.<\/p>\n\n\n\n
      This matters in a handful of scenarios:<\/p>\n\n\n\n
      Reflection.<\/strong> If you’re using reflection to enumerate a type’s fields \u2014 for serialization, mapping, testing, or any other purpose \u2014 the synthesized backing field will show up under its compiler-generated name. Code that filters fields by name or naming convention needs to account for this. The field name is not stable across compiler versions either, though in practice the convention hasn’t changed in many years.<\/p>\n\n\n\n
      Binary serialization.<\/strong> If you’re using BinaryFormatter<\/code> (though you shouldn’t be in new code) or any other serialization mechanism that persists field names, renaming the property will change the backing field’s name and break deserialization of previously serialized data. This is the same issue that exists with auto-properties and is not new, but it’s easy to forget.<\/p>\n\n\n\n
      Source generators and analyzers.<\/strong> If you’re writing or maintaining a source generator or Roslyn analyzer that inspects property backing fields, you need to handle the case where the backing field is synthesized rather than explicitly declared. The IPropertySymbol<\/code> in Roslyn exposes a BackingField<\/code> property that returns the synthesized field symbol for both auto-properties and semi-auto properties, so the API surface is there \u2014 but generators that work by inspecting field declarations directly rather than through the property symbol will miss synthesized fields.<\/p>\n\n\n\n
      Initializer Bypass<\/h3>\n\n\n\n
      We mentioned this briefly in section 4, but it deserves explicit emphasis because it’s a source of real bugs. Property initializers and constructor assignments bypass accessor logic.<\/strong> When you write:<\/p>\n\n\n
      public<\/span> class<\/span> Product<\/span>\n{\n    public<\/span> decimal<\/span> Price\n    {\n        get<\/span>;\n        set<\/span>\n        {\n            if<\/span> (value<\/span> < 0<\/span>) throw<\/span> new<\/span> ArgumentOutOfRangeException(nameof<\/span>(value<\/span>));\n            field = value<\/span>;\n        }\n    } = -1<\/span>; \/\/ initializer<\/span>\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      The initializer = -1<\/code> bypasses the setter entirely and writes directly to the backing field. You now have a Product<\/code> with a Price<\/code> of -1<\/code> before any constructor logic runs, which directly violates the invariant your setter is trying to enforce. The same applies to assignments in constructors for get-only properties \u2014 the assignment goes directly to the backing field, not through any accessor.<\/p>\n\n\n\n
      If you need invariants enforced at initialization time, you have two options: validate in the constructor explicitly after setting the property, or use an init<\/code> accessor with a setter-style body that runs validation, and set the property via an object initializer rather than a field initializer.<\/p>\n\n\n\n
      Interaction with nameof<\/code><\/h3>\n\n\n\n
      Inside an accessor body, nameof(field)<\/code> does not return \"field\"<\/code>. It returns the compiler-generated field name, which is something like <Price>k__BackingField<\/code>. This is almost certainly not what you want if you’re using nameof<\/code> for error messages or logging:<\/p>\n\n\n
      public<\/span> decimal<\/span> Price\n{\n    get<\/span>;\n    set<\/span>\n    {\n        if<\/span> (value<\/span> < 0<\/span>)\n            throw<\/span> new<\/span> ArgumentOutOfRangeException(nameof<\/span>(field)); \/\/ returns \"<Price>k__BackingField\"<\/span>\n        field = value<\/span>;\n    }\n}<\/code><\/span>Code language:<\/span> C#<\/span> (<\/span>cs<\/span>)<\/span><\/small><\/pre>\n\n\n
      Use nameof(value)<\/code> for the parameter in setter exception messages, or the property name directly via nameof(Price)<\/code>, rather than nameof(field)<\/code>. This is a minor footgun but one that shows up in exception messages visible to developers and sometimes end users.<\/p>\n\n\n\n
      No Cross-Accessor Field References Outside Properties<\/h3>\n\n\n\n
      field<\/code> is strictly scoped to the accessor in which it appears. You cannot reference field<\/code> from a method, a constructor body (beyond the implicit assignment behavior for get-only properties), or any other context outside a property accessor. This is by design, but it creates a genuine limitation for patterns where you want to reset or directly manipulate the backing value from within the class without going through the property’s accessor logic.<\/p>\n\n\n\n
      For example, if your setter validates and normalizes input, but you have an internal method that needs to set the backing value to a known-valid state without triggering that logic, you have no way to do that with a semi-auto property. You need a full property with an explicit backing field that your internal method can reach directly. This is a real and intentional trade-off \u2014 the encapsulation of field<\/code> within the accessor body is what makes semi-auto properties safe and predictable \u2014 but it’s a limitation to be aware of.<\/p>\n\n\n\n
      LangVersion<\/code> Mismatches and Silent Failures<\/h3>\n\n\n\n
      If your project’s LangVersion<\/code> is set below 13 and you write code that uses field<\/code> inside a property accessor, the compiler won’t treat it as the backing field keyword \u2014 it will treat it as a regular identifier. Depending on context, this could mean it compiles successfully but does something completely wrong, or it produces an error because field<\/code> as an identifier isn’t declared anywhere in scope.<\/p>\n\n\n\n
      The insidious case is when field<\/code> happens to be a valid identifier in scope \u2014 a field or local variable of that name somewhere in the type \u2014 and the code compiles cleanly but behaves incorrectly because field<\/code> is resolving to the wrong thing entirely. If you’re working in a multi-project solution with different LangVersion<\/code> settings, or if you copy semi-auto property code into a project targeting an older language version, this is worth checking explicitly. A quick look at the project file’s <LangVersion><\/code> element will tell you whether the feature is available.<\/p>\n\n\n\n
      Serialization Frameworks and Field Discovery<\/h3>\n\n\n\n
      Several popular serialization frameworks \u2014 Newtonsoft.Json with certain settings, MessagePack, MemoryPack, and others \u2014 can be configured to serialize fields rather than or in addition to properties. When these frameworks discover fields via reflection, they will find the synthesized backing field for semi-auto properties and may attempt to serialize it, producing duplicate data in the output (once from the field, once from the property) or unexpected JSON keys based on the compiler-generated field name.<\/p>\n\n\n\n
      The solution is the [field: JsonIgnore]<\/code> or equivalent attribute targeting discussed in section 7. But the point here is that this isn’t just a theoretical concern \u2014 it’s an active gotcha for anyone migrating from auto-properties or full properties to semi-auto properties in a codebase that uses field-level serialization. Audit your serialization configuration and test your serialized output when migrating.<\/p>\n\n\n\n
      One Thing field<\/code> Simply Cannot Do<\/h3>\n\n\n\n
      It’s worth ending this section with a clear statement of the feature’s fundamental constraint: field<\/code> gives you access to a single, compiler-managed backing store for the property. You cannot have two synthesized fields for one property, you cannot control the field’s type independently of the property type, and you cannot give the field a name that’s meaningful outside the property body. If any of those things matter for your use case, a full property with one or more explicitly declared backing fields is the right tool. Semi-auto properties are not trying to replace that pattern \u2014 they’re trying to eliminate the cases where you reach for it out of habit or necessity when you don’t actually need that level of control.<\/p>\n\n\n\n
      11. Tooling and IDE Support<\/h2>\n\n\n\n
      A language feature is only as usable as the tooling around it, and it’s worth knowing what Visual Studio, JetBrains Rider, and the underlying Roslyn compiler actually offer when you’re working with semi-auto properties day to day. The short version is that support is solid, with a few rough edges you should know about before you lean on the tooling too heavily.<\/p>\n\n\n\n
      Roslyn Analyzer Support<\/h3>\n\n\n\n
      The Roslyn compiler ships with a set of built-in analyzers that understand semi-auto properties at a semantic level. The most immediately useful of these is the analyzer that detects when a full property with an explicit backing field could be simplified to a semi-auto property. In Visual Studio and any editor running the Roslyn language server, this surfaces as a suggestion \u2014 typically a grey underline on the backing field declaration \u2014 with a quick fix action that performs the migration automatically.<\/p>\n\n\n\n
      The suggested refactoring handles the straightforward cases well: it removes the backing field, rewrites the getter and setter to use field<\/code>, and cleans up any now-unnecessary field references. For simple validation and normalization patterns, the automatic migration is reliable and worth using. For more complex patterns \u2014 particularly where the backing field is referenced from multiple places in the class, or where the field has attributes that need to be migrated to [field: ...]<\/code> syntax \u2014 the analyzer is more conservative and may not offer the refactoring at all, which is the correct behavior. An analyzer that tries to be too clever about complex migrations causes more problems than it solves.<\/p>\n\n\n\n
      The shadowing warning discussed in section 10 \u2014 where a local variable named field<\/code> inside an accessor shadows the keyword \u2014 is also surfaced by Roslyn as a compiler warning rather than just a style suggestion. This means it will appear in your build output and can be treated as a build error if your project uses <TreatWarningsAsErrors>true<\/TreatWarningsAsErrors><\/code>. For teams adopting semi-auto properties at scale, this is worth enabling or at least monitoring.<\/p>\n\n\n\n
      Visual Studio<\/h3>\n\n\n\n
      In Visual Studio 17.8 and later (the versions aligned with C# 13 preview and release), IntelliSense is fully aware of the field<\/code> keyword inside property accessor bodies. It offers completion for field<\/code>, shows the correct type information in hover tooltips, and navigates correctly when you use “Go to Definition” on field<\/code> \u2014 though since there’s no explicit declaration to navigate to, it typically highlights the property declaration itself, which is the most useful thing it can do.<\/p>\n\n\n\n
      The “Refactor” menu includes the migration action mentioned above when the analyzer detects a convertible pattern. You can also trigger it via the lightbulb menu (Ctrl+.) when your cursor is on the backing field or the property declaration. The rename refactoring is unaffected by semi-auto properties in any meaningful way \u2014 renaming the property renames the property, and the synthesized backing field’s compiler-generated name updates automatically since it’s derived from the property name.<\/p>\n\n\n\n
      One area where Visual Studio’s support is still maturing is the debugger experience. The synthesized backing field shows up in the Locals and Autos windows under its compiler-generated name during debugging, which is cluttered and rarely useful. Applying [field: DebuggerBrowsable(DebuggerBrowsableState.Never)]<\/code> as discussed in section 7 is currently a manual step \u2014 Visual Studio doesn’t automatically suppress synthesized backing fields the way it does for auto-property backing fields. This is a tooling gap that will likely close in a future Visual Studio update, but for now it’s worth being aware of if you do a lot of property-level debugging.<\/p>\n\n\n\n
      JetBrains Rider<\/h3>\n\n\n\n
      Rider’s support for semi-auto properties follows its usual pattern of being slightly ahead of Visual Studio on language feature adoption. The ReSharper-based engine that powers Rider’s code analysis understands field<\/code> semantically and offers the same class of migration suggestions as Roslyn, with the addition of Rider’s more aggressive inspection suite which can catch a broader range of convertible patterns.<\/p>\n\n\n\n
      Rider’s parameter information and type inference hints work correctly for field<\/code> \u2014 hovering over field<\/code> in an accessor body shows the inferred type, and the inline type hint feature (if you have it enabled) displays the type next to field<\/code> in the editor, which is useful when the property type is a long generic name and you want a quick reminder of what you’re working with without scrolling to the property declaration.<\/p>\n\n\n\n
      The debugger integration in Rider handles the synthesized backing field slightly more gracefully than Visual Studio out of the box, grouping compiler-generated members separately in the debug view rather than mixing them with explicitly declared fields. This doesn’t eliminate the noise entirely, but it makes it easier to find what you’re looking for during a debugging session.<\/p>\n\n\n\n
      What the Decompiler Reveals<\/h3>\n\n\n\n
      If you open a compiled assembly containing semi-auto properties in ILSpy, dnSpy, dotPeek, or the decompiler built into Rider, you’ll see the synthesized backing field exposed as a regular private field with its compiler-generated name. The decompiler will typically round-trip the code back to a full property with an explicit backing field rather than reconstructing the semi-auto syntax, because the compiled IL contains no metadata indicating that the property was originally written as a semi-auto property \u2014 that information exists only in source.<\/p>\n\n\n\n
      This is worth knowing for two reasons. First, if you’re inspecting third-party code in a decompiler and see a full property with a k__BackingField<\/code>-named field, it might have been written as a semi-auto property originally \u2014 you can’t tell from the IL alone. Second, the decompiled output gives you a useful sanity check on what the compiler is actually generating. For most semi-auto properties, the decompiled output is identical to what you would have written as a full property before the feature existed, which confirms that there’s no runtime overhead or behavioral difference \u2014 it’s purely a source-level convenience.<\/p>\n\n\n\n
      For IL-level inspection, the synthesized backing field is marked with [CompilerGenerated]<\/code> just like auto-property backing fields, which is how tools and frameworks can distinguish synthesized fields from explicitly declared ones when they need to. If you’re writing tooling that inspects assemblies, filtering on [CompilerGenerated]<\/code> is the right approach rather than relying on naming conventions.<\/p>\n\n\n\n
      dotnet format<\/code> and EditorConfig<\/h3>\n\n\n\n
      At the time of writing, dotnet format<\/code> doesn’t enforce any specific style rules around semi-auto property usage \u2014 it won’t automatically migrate full properties to semi-auto properties as part of a format pass. Style preferences around when to use semi-auto properties vs. full properties are currently expressed through Roslyn analyzer severity settings in .editorconfig<\/code> rather than through formatting rules. If your team wants to enforce consistent usage, the place to configure that is the analyzer severity for the relevant diagnostic IDs, which you can set to suggestion<\/code>, warning<\/code>, or error<\/code> depending on how strictly you want to enforce the pattern.<\/p>\n\n\n\n
      12. When to Use Semi-Auto Properties vs. Full Properties<\/h2>\n\n\n\n
      After nine sections of detail, it’s worth stepping back and answering the practical question every developer will eventually ask standing in front of a property declaration: should I use field<\/code> here, or just write a full property?<\/em><\/p>\n\n\n\n
      The honest answer is that for most cases the decision is obvious once you’ve internalized what the feature is for. Semi-auto properties solve a specific problem \u2014 compiler-managed backing storage with custom accessor logic \u2014 and the cases where they’re the right tool are easy to recognize. The cases where a full property is still warranted are equally clear, and it’s important not to reach for field<\/code> out of novelty when a named backing field is genuinely the better choice.<\/p>\n\n\n\n
      Use Semi-Auto Properties When<\/h3>\n\n\n\n
      You need one thing from a backing field: storage.<\/strong> If the only reason you’d declare a private backing field is to have somewhere to put the value, and everything else about the property is standard get\/set or get\/init behavior with some logic wrapped around it, field<\/code> is the right choice. The field name adds no value, the declaration adds no clarity, and removing both makes the code strictly easier to read.<\/p>\n\n\n\n
      The logic is self-contained within the accessor.<\/strong> Validation, normalization, trimming, clamping, coalescing \u2014 any logic that lives entirely inside the getter or setter without needing to reach outside the property \u2014 is a natural fit. The encapsulation that field<\/code> enforces, where the backing store is only accessible through the accessors, is a feature rather than a limitation in these cases. It guarantees that your accessor logic is the only path to the stored value.<\/p>\n\n\n\n
      You’re working with immutable or init-only properties.<\/strong> The combination of required<\/code>, init<\/code>, and field<\/code> is probably the most compelling use case for the feature in everyday application code. Domain entities, value objects, DTOs with validation \u2014 anything that needs to be set once, validated on the way in, and immutable afterward is an ideal candidate. The pattern is expressive, the intent is clear, and it requires no supporting infrastructure.<\/p>\n\n\n\n
      You’re migrating an existing auto-property that grew a small amount of logic.<\/strong> This is the most common real-world trigger. You had a clean { get; set; }<\/code> and a new requirement arrived \u2014 a range check, a default value, a normalization step. Previously your only option was a full migration to a backing field. Now you can add the logic you need without restructuring the property at all. If the Roslyn analyzer offers you the migration automatically, take it.<\/p>\n\n\n\n
      Use a Full Property When<\/h3>\n\n\n\n
      The backing field needs to be accessed from outside the property’s accessors.<\/strong> If a method, constructor, or other property in the same type needs to read or write the backing value directly \u2014 bypassing the property’s accessor logic \u2014 you need a named field. There’s no workaround here: field<\/code> is strictly accessor-scoped, and that’s not going to change. Any pattern involving Interlocked<\/code>, direct field manipulation for performance reasons, or internal reset logic that bypasses validation falls into this category.<\/p>\n\n\n\n
      You need more than one backing value.<\/strong> A property that computes its result from two private fields, or that maintains both a raw and a processed version of its value, needs explicit field declarations. field<\/code> gives you exactly one synthesized backing store per property, and you can’t get around that limit.<\/p>\n\n\n\n
      You need volatile<\/code> on the backing field.<\/strong> As covered in section 9, volatile<\/code> is a field modifier rather than an attribute, so it can’t be applied through the [field: ...]<\/code> target syntax. Any property in a multithreaded context that requires volatile<\/code> semantics needs a full property with an explicit backing field.<\/p>\n\n\n\n
      The backing field type needs to differ from the property type.<\/strong> The synthesized field<\/code> always has the same type as the property. If you’re storing a Lazy<T><\/code> behind a T<\/code>-typed property, or an int<\/code> behind an enum<\/code>-typed property, or anything else where the stored type and the exposed type diverge, you need an explicit backing field with the correct type.<\/p>\n\n\n\n
      The field has meaningful semantics beyond just storing the property value.<\/strong> If the backing field participates in serialization in a way that requires careful naming, or if it needs to be a specific named member for interop reasons, or if its existence as a named class member is itself meaningful to the design, an explicit declaration communicates that intentionality. Compiler-generated fields are implementation details; named fields are part of the type’s structure.<\/p>\n\n\n\n
      The Rule of Thumb<\/h3>\n\n\n\n
      Here’s a simple test that covers the majority of cases: if you would name the backing field _propertyName<\/code> and use it for nothing other than storing and returning the property’s value, use field<\/code>. If you’d name it something else, or use it for anything beyond simple storage, use a full property.<\/strong><\/p>\n\n\n\n
      The naming test works because a backing field named _price<\/code> for a property named Price<\/code> is purely mechanical \u2014 it exists because the language required it, not because the name or the explicit declaration adds anything. That’s exactly the case field<\/code> is designed to eliminate. A backing field named _cachedResult<\/code>, _lazyLoader<\/code>, _rawBytes<\/code>, or anything other than a straightforward underscore-prefixed version of the property name is carrying semantic weight that deserves to be explicit.<\/p>\n\n\n\n
      Semi-auto properties are a quality-of-life improvement for a specific, common pattern. They’re not a replacement for full properties, and treating them as a default you apply everywhere will lead to code that works but reaches for field<\/code> in cases where a named backing field would communicate intent more clearly. Use the feature where it genuinely simplifies things, and reach for a full property without hesitation when the situation calls for it.<\/p>\n\n\n\n
      13. Conclusion<\/h2>\n\n\n\n
      Semi-auto properties and the field<\/code> keyword are a small addition to C# in the grand scheme of language evolution. There’s no new runtime behavior, no new type system concept, no shift in how you think about object-oriented design. What there is, is the elimination of a specific piece of friction that C# developers have been working around since auto-properties were introduced in 2007.<\/p>\n\n\n\n
      That friction \u2014 the all-or-nothing choice between a convenient auto-property and a verbose full property \u2014 was never catastrophic. Developers wrote the backing fields, named them carefully, kept them in sync, and moved on. But the cost was real: noise in the codebase, surface area for bugs, and a subtle pressure against adding validation or normalization logic because the structural overhead felt disproportionate to the change.<\/p>\n\n\n\n
      field<\/code> removes that pressure. The backing field is still there \u2014 the compiler generates it \u2014 but you don’t see it, name it, or maintain it. You write the logic you actually care about, and the rest is handled for you. The result is code that more directly expresses intent, with fewer moving parts between what you write and what you mean.<\/p>\n\n\n\n
      The feature lands especially well in combination with patterns C# has been building toward for several versions: init<\/code> accessors from C# 9, required<\/code> members from C# 11, and the broader push toward more expressive, less ceremonial type declarations that has characterized the language’s recent evolution. Put those together and you have a genuinely compelling model for immutable-by-default types with construction-time validation \u2014 domain entities, value objects, and DTOs that enforce their own invariants without frameworks or base classes to lean on.<\/p>\n\n\n\n
      If there’s one thing to take away from this tutorial, it’s the rule of thumb from the previous section: if you’d name the backing field _propertyName<\/code> and use it for nothing other than storing the property’s value, field<\/code> is the right call. Everything else stays a full property. That simple test will get you to the right answer in the vast majority of cases, and the rest of the nuance \u2014 thread safety, struct semantics, record equality, attribute targeting \u2014 is there when you need it.<\/p>\n\n\n\n
      C# continues to be a language that takes its existing user base seriously, adding expressiveness without breaking what came before. Semi-auto properties are a good example of that philosophy done well: a pragmatic, backward-compatible improvement to a pattern that every C# developer has written hundreds of times. It won’t change how you think about the language, but it will quietly make your code a little cleaner, one property at a time.<\/p>\n","protected":false},"excerpt":{"rendered":"
      1. Introduction Auto-properties were a welcome addition back in C# 3.0. Instead of declaring a private backing field, writing a getter that returns it, and writing a setter that assigns to it, you could collapse all of that into a single line. Clean, fast, done. But that convenience came with a hard ceiling. The moment […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[8,4],"tags":[],"class_list":["post-2280","post","type-post","status-publish","format-standard","category-csharp","category-programming-languages","entry"],"yoast_head":"\nSemi-Auto Properties and the field Keyword in C#<\/title>\n<meta name=\"description\" content=\"The name "semi-auto property" isn't an official C# specification term \u2014 it's the shorthand the community and the C# team landed on to describe what this feature actually is\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Semi-Auto Properties and the field Keyword in C#\" \/>\n<meta property=\"og:description\" content=\"The name "semi-auto property" isn't an official C# specification term \u2014 it's the shorthand the community and the C# team landed on to describe what this feature actually is\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-20T20:27:34+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-02-20T20:27:42+00:00\" \/>\n<meta name=\"author\" content=\"w3compadmin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"w3compadmin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"41 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"TechArticle\",\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/semi-auto-properties-field-keyword-csharp\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/semi-auto-properties-field-keyword-csharp\\\/\"},\"author\":{\"name\":\"w3compadmin\",\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/#\\\/schema\\\/person\\\/a550b3e20d78bb4f79b7c6b7b53f0561\"},\"headline\":\"Semi-Auto Properties and the field Keyword in C#\",\"datePublished\":\"2026-02-20T20:27:34+00:00\",\"dateModified\":\"2026-02-20T20:27:42+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/semi-auto-properties-field-keyword-csharp\\\/\"},\"wordCount\":9452,\"articleSection\":[\"C#\",\"Programming Languages\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/semi-auto-properties-field-keyword-csharp\\\/\",\"url\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/semi-auto-properties-field-keyword-csharp\\\/\",\"name\":\"Semi-Auto Properties and the field Keyword in C#\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/#website\"},\"datePublished\":\"2026-02-20T20:27:34+00:00\",\"dateModified\":\"2026-02-20T20:27:42+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/#\\\/schema\\\/person\\\/a550b3e20d78bb4f79b7c6b7b53f0561\"},\"description\":\"The name \\\"semi-auto property\\\" isn't an official C# specification term \u2014 it's the shorthand the community and the C# team landed on to describe what this feature actually is\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/semi-auto-properties-field-keyword-csharp\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/semi-auto-properties-field-keyword-csharp\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/semi-auto-properties-field-keyword-csharp\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Articles Home\",\"item\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Programming Languages\",\"item\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/programming-languages\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Semi-Auto Properties and the field Keyword in C#\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/#website\",\"url\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/\",\"name\":\"Developer Articles Hub\",\"description\":\"\",\"alternateName\":\"Developer Articles\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/#\\\/schema\\\/person\\\/a550b3e20d78bb4f79b7c6b7b53f0561\",\"name\":\"w3compadmin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/wp-content\\\/litespeed\\\/avatar\\\/bd481d404e42caa2763662a3bfe825f8.jpg?ver=1780141266\",\"url\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/wp-content\\\/litespeed\\\/avatar\\\/bd481d404e42caa2763662a3bfe825f8.jpg?ver=1780141266\",\"contentUrl\":\"https:\\\/\\\/www.w3computing.com\\\/articles\\\/wp-content\\\/litespeed\\\/avatar\\\/bd481d404e42caa2763662a3bfe825f8.jpg?ver=1780141266\",\"caption\":\"w3compadmin\"},\"sameAs\":[\"http:\\\/\\\/w3computing.com\\\/articles\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Semi-Auto Properties and the field Keyword in C#","description":"The name \"semi-auto property\" isn't an official C# specification term \u2014 it's the shorthand the community and the C# team landed on to describe what this feature actually is","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/","og_locale":"en_US","og_type":"article","og_title":"Semi-Auto Properties and the field Keyword in C#","og_description":"The name \"semi-auto property\" isn't an official C# specification term \u2014 it's the shorthand the community and the C# team landed on to describe what this feature actually is","og_url":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/","article_published_time":"2026-02-20T20:27:34+00:00","article_modified_time":"2026-02-20T20:27:42+00:00","author":"w3compadmin","twitter_card":"summary_large_image","twitter_misc":{"Written by":"w3compadmin","Est. reading time":"41 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"TechArticle","@id":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/#article","isPartOf":{"@id":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/"},"author":{"name":"w3compadmin","@id":"https:\/\/www.w3computing.com\/articles\/#\/schema\/person\/a550b3e20d78bb4f79b7c6b7b53f0561"},"headline":"Semi-Auto Properties and the field Keyword in C#","datePublished":"2026-02-20T20:27:34+00:00","dateModified":"2026-02-20T20:27:42+00:00","mainEntityOfPage":{"@id":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/"},"wordCount":9452,"articleSection":["C#","Programming Languages"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/","url":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/","name":"Semi-Auto Properties and the field Keyword in C#","isPartOf":{"@id":"https:\/\/www.w3computing.com\/articles\/#website"},"datePublished":"2026-02-20T20:27:34+00:00","dateModified":"2026-02-20T20:27:42+00:00","author":{"@id":"https:\/\/www.w3computing.com\/articles\/#\/schema\/person\/a550b3e20d78bb4f79b7c6b7b53f0561"},"description":"The name \"semi-auto property\" isn't an official C# specification term \u2014 it's the shorthand the community and the C# team landed on to describe what this feature actually is","breadcrumb":{"@id":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.w3computing.com\/articles\/semi-auto-properties-field-keyword-csharp\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Articles Home","item":"https:\/\/www.w3computing.com\/articles\/"},{"@type":"ListItem","position":2,"name":"Programming Languages","item":"https:\/\/www.w3computing.com\/articles\/programming-languages\/"},{"@type":"ListItem","position":3,"name":"Semi-Auto Properties and the field Keyword in C#"}]},{"@type":"WebSite","@id":"https:\/\/www.w3computing.com\/articles\/#website","url":"https:\/\/www.w3computing.com\/articles\/","name":"Developer Articles Hub","description":"","alternateName":"Developer Articles","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.w3computing.com\/articles\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.w3computing.com\/articles\/#\/schema\/person\/a550b3e20d78bb4f79b7c6b7b53f0561","name":"w3compadmin","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.w3computing.com\/articles\/wp-content\/litespeed\/avatar\/bd481d404e42caa2763662a3bfe825f8.jpg?ver=1780141266","url":"https:\/\/www.w3computing.com\/articles\/wp-content\/litespeed\/avatar\/bd481d404e42caa2763662a3bfe825f8.jpg?ver=1780141266","contentUrl":"https:\/\/www.w3computing.com\/articles\/wp-content\/litespeed\/avatar\/bd481d404e42caa2763662a3bfe825f8.jpg?ver=1780141266","caption":"w3compadmin"},"sameAs":["http:\/\/w3computing.com\/articles"]}]}},"featured_image_src":null,"featured_image_src_square":null,"author_info":{"display_name":"w3compadmin","author_link":"https:\/\/www.w3computing.com\/articles\/author\/w3compadmin\/"},"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/posts\/2280","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/comments?post=2280"}],"version-history":[{"count":7,"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/posts\/2280\/revisions"}],"predecessor-version":[{"id":2287,"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/posts\/2280\/revisions\/2287"}],"wp:attachment":[{"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/media?parent=2280"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/categories?post=2280"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.w3computing.com\/articles\/wp-json\/wp\/v2\/tags?post=2280"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}