How the New field Keyword Improves C# Properties

Overview of C# Properties and the Upgrade in C# 14

Tim starts by explaining that there is a big upgrade to C# properties in C# 14. He makes it clear that the focus of the video is the new field keyword, which affects how auto properties work internally. Tim also mentions that C# 14 ships alongside .NET 10 and Visual Studio 2026, although the feature itself may work in earlier .NET versions.

He frames the video as a quick, focused explanation, designed to answer one specific question: how do we use this new feature in real code? This sets the tone for a hands-on walkthrough rather than a theoretical discussion of property definition.

The Person Class Example and Auto Properties

At around 0:23, Tim introduces a console application with a simple public class Person. This person class contains several public properties, including:

• public string FirstName

• public string LastName

• public int Age

Tim explains that these are auto implemented properties (also called automatically implemented properties). There are no visible private variables or private fields because the compiler automatically creates a backing field behind the scenes.

He also includes a Demo property that is not auto-implemented. Instead, it uses a private string backing field (_demo) and exposes a read only property using only a get accessor. This contrast becomes important later in the video.

Using Properties in Program.cs

Tim then moves into class Program and shows how the Person object is created inside public static void main (or static void main string args, conceptually). He instantiates a new person using:

new Person { FirstName = "Tim", LastName = "Corey" }

Tim points out that properties allow access outside the class while still hiding private data members. He retrieves values like last name, age, and demo, showing how properties appear just like fields when accessed, even though they are actually special methods under the hood.

The Problem with Invalid Values in Auto Properties

At about 1:23, Tim deliberately assigns an invalid value:

person.LastName = null;

Even though LastName is required and not marked nullable, the assignment still works at runtime. Tim explains that auto properties do not automatically protect against invalid values. The compiler warns you, but the set method still accepts the value.

This demonstrates a key issue with auto implemented properties: while they are concise, they provide no built-in way to add validation. Invalid data can pass through and silently break assumptions.

The Traditional Full Property with Backing Field

Around 2:58, Tim shows what developers used to do in earlier versions of C#. He converts LastName into a fully implemented property with:

• A private string backing field

• A set accessor that checks the property value

• An exception thrown for invalid values

This approach gives full control over the property accessors, but Tim emphasizes how verbose it becomes. The property now takes several lines, compared to the single-line syntax of auto properties.

He also explains that switching from an auto property to a full property does not break existing code, since the property name, accessibility level, and external usage remain the same.

The New field Keyword as a Middle Ground

At 4:19, Tim introduces the key improvement in C# 14. Instead of writing a full property, he keeps the auto property structure and modifies only the set accessor using the field keyword.

Tim explains that field represents the compiler-generated private field that normally remains hidden. By assigning field = value, developers can now intercept and validate the property value without declaring their own private variable.

This preserves the same syntax developers are used to while adding flexibility. Tim highlights that this reduces code while still allowing validation logic, placing it between auto properties and full properties.

Scoped Backing Fields and Property Isolation

Tim explains that the field keyword is scoped to the property where it appears. Each property gets its own backing field, and there is no risk of cross-property interference.

If the same syntax is used in another property—such as FirstName—it refers to that property’s own backing field. This makes the feature predictable and safe to use across multiple public properties.

Validating Numeric Properties Like Age

At around 6:16, Tim applies the same approach to a public int Age property. He assigns an invalid negative value and explains why it should not be allowed.

Instead of throwing an exception, Tim shows a different strategy: ignoring invalid values. The set method checks if the value is within a valid range before assigning it to field.

This demonstrates that the new approach works equally well for private int age, numeric validation, and conditional logic—all without converting the property into a full implementation.

Naming Conflicts with the field Keyword

Tim then discusses a potential edge case: naming conflicts. If a class already contains a variable named field, it can conflict with the new keyword inside properties.

He demonstrates how this causes confusion and unexpected behavior. Tim explains that the solution is to explicitly reference the variable using this.field or @field. This distinguishes the variable name from the backing field keyword.

Tim strongly recommends renaming such variables as a good practice, especially when upgrading existing codebases.

Where Naming Conflicts Do Not Apply

Tim clarifies that the field keyword only has special meaning inside property accessors. In constructors, methods, or other parts of the class, field behaves like a normal variable.

This distinction helps developers understand when the compiler-generated backing field exists and when it does not.

Final Thoughts from Tim Corey

Tim concludes his video by summarizing how the new field keyword works and why it improves properties in C#. It allows developers to keep using automatic properties while adding validation, control, and clarity.

He encourages viewers to try the feature, explore how it fits into their coding style, and think carefully about naming conventions. Tim closes the video by reinforcing that this change makes properties more expressive without adding unnecessary complexity.