C# 10 Record Structs: A Practical Guide to Value-Type Immutability

The C# Corner Annual Conference 2020 brings together developers from across Australia and beyond, and a quiet shift in the language kept surfacing in Sydney and Melbourne sessions. With C# 10, the runtime shipped record structs, a feature that finally gave value types the same concise, immutable ergonomics that record classes had enjoyed since C# 9. For Australian teams maintaining financial ledgers, telco billing engines, or geospatial pipelines, this is a meaningful change rather than a syntactic curiosity.

Developers who grew up on plain structs often reached for them only when chasing tight memory layouts, accepting the boilerplate of manual constructors and Equals overrides. Record structs collapse that ceremony into a single declaration while preserving the value semantics that make structs attractive. The result is code that reads more like a domain model and less like a low-level buffer.

This guide walks through how to define record structs, how their copy-and-update behaviour differs from record classes, and where they fit into performance-conscious Australian workloads. You will find practical patterns, a few pitfalls worth avoiding, and notes on when a record struct is genuinely the right tool for the job.

Why value-type immutability earns a second look

Immutability has long been the domain of reference types in C#, but value types always had a hidden advantage. When a struct is read-only, its bits cannot mutate underneath you, no matter which thread observes them. That guarantee lets immutable record structs behave safely in concurrent pipelines without locks. A pricing engine crunching through Sydney exchange-rate snapshots or a logistics router optimising Brisbane courier routes can hand the same record struct to multiple workers without defensive copying.

The classic objection was that writing immutable structs was painful: a constructor for every field combination, plus overridden Equals, GetHashCode, and IEquatable<T>. Most teams quietly skipped the immutability and accepted the bugs that followed. C# 9 introduced records to remove that friction for classes, and C# 10 extends the same syntactic sugar to structs. The compiler now generates the equality members, the deconstructor, and a developer-friendly ToString, so you write the shape and the runtime enforces the contract.

There is also a predictability win beyond threading. Hash codes for a record struct are computed from its fields and cached in a hidden field, which means a struct placed in a Dictionary does not rehash itself on every lookup the way a hand-rolled struct sometimes did. For Australian teams porting legacy interest-rate calculators, that stability alone justifies the migration.

Record classes versus record structs at a glance

The two record kinds share most of their syntax, but the differences matter at runtime. A record class is a reference type, lives on the heap, and uses reference equality before generated equality kicks in. A record struct is a value type, lives wherever it is stored, and uses bitwise value equality from the start. That single distinction changes how you reason about copying, identity, and lock-free sharing.

Key differences worth keeping in your head:

• Allocation: record class instances always allocate on the heap; record struct instances allocate on the stack unless boxed or captured.
• Equality: record classes compare structural values, but null checks still trip reference-style comparisons; record structs never produce a null reference.
• Inheritance: record classes support inheritance; record structs are sealed and cannot be subclassed.
• Mutability surface: a record struct pairs naturally with the readonly modifier because every field is private and settable only through the constructor.

For most DTOs flowing across service boundaries, a record class remains the safer default. The case for record structs sharpens when you are modelling a fixed tuple of numbers, coordinates, or monetary amounts that benefit from value semantics and minimal allocation pressure.

Declaring and instantiating a record struct

The syntax mirrors record classes almost exactly, with struct replacing class. A record struct representing an Australian post code region might hold the four-digit code, the state abbreviation, and a latitude/longitude pair. Once declared, the compiler emits a primary constructor, readonly auto-properties, a value-based Equals, a matching GetHashCode, and a developer-friendly ToString.

Positional record structs can be written on a single line, which is where the feature feels most transformative. Something like public readonly record struct Price(decimal Amount, string Currency) defines an immutable money type that prints as Price { Amount = 19.95, Currency = AUD } out of the box. The readonly modifier is the recommendation rather than a requirement, but marking the struct readonly closes the door on accidental mutation through any path.

Instantiation looks like a normal struct construction: var audPrice = new Price(19.95m, "AUD"). There is no parameterless constructor unless you declare one explicitly, which is a subtle but important difference from plain structs. For Australian codebases that historically relied on default(T) checks, this is a chance to retire that habit in favour of explicit construction.

Positional and nominal parameters in practice

Positional record structs are excellent for compact tuples-of-meaning, but sometimes you want named members with sensible defaults. Both flavours can coexist: a record struct can declare explicit properties alongside a primary constructor, giving you the readability of named fields and the convenience of positional syntax. This pattern is common in Australian actuarial code, where some risk parameters have regulatory defaults while others are case-specific.

A reasonable hybrid might look like public record struct PolicyHolder(string Id, string Name) with an additional public string Region { get; init; } = "NSW". The constructor validates the required identifiers, while the optional region defaults sensibly for the Sydney office without forcing every callsite to supply it. The init-only setter preserves the immutability contract because nothing outside the constructor or an object initialiser can touch it.

Deconstruction is also free. A tuple-style (var id, var name) = policyHolder unpacks the positional parameters in the order they were declared, which is handy when a record struct represents a multi-field result returned from a calculation. Compare that to the explicit deconstruct method you would otherwise have to write on a hand-rolled struct, and the productivity gain becomes obvious.

Copy-and-update with the With expression

The with expression is one of the headline features of records, and it works on record structs too, with a small but important twist. Because a record struct is a value type, the compiler creates a defensive copy of every field, applies the overrides you specify, and returns the new instance as another value. There is no heap allocation for the copy itself, which is what makes the pattern attractive on hot paths.

A typical use case is a small immutable pipeline stage: start with a base Price, derive a discountedPrice with with { Amount = basePrice.Amount * 0.9m }, and pass that onward. Australian teams running promotional pricing for retailers often build entire rule chains this way, with each stage producing the next record struct without touching shared state. The pattern also composes well with switch expressions that compute a fully re-priced record struct in a single line.

One behavioural nuance is worth flagging. Because the compiler uses bitwise copy semantics, a record struct containing a mutable field such as a List<T> is not deeply immutable. The reference inside the struct is copied, not the object it points to. Treat record structs as shallowly immutable and keep their fields restricted to other immutable types or other record structs.

Performance and memory considerations

The strongest argument for record structs is allocation behaviour. A record class returned from a method hands the caller a reference to a heap-allocated object the garbage collector must eventually walk. A record struct hands the caller a value; if it fits in a register or on the stack, no allocation occurs. For inner loops in Australian trading systems, route planners, or simulation code, the difference can be the gap between fitting the latency budget and tipping into Gen 0 collections.

Mobile and embedded scenarios magnify the benefit. Developers optimising record structs for low-end devices often care about every byte that crosses the allocation boundary, and that mindset is shared by teams shipping niche apps beyond enterprise stacks. Whether you are tuning a transport tracker on field-worker phones or lightweight entertainment software such as poker machines on Android, the same rules apply: prefer stack-resident values for short-lived data and reach for record classes only when you genuinely need reference identity or polymorphism.

The boxing trap remains alive. The moment a record struct is assigned to an interface, passed as object, or stored in a non-generic collection, it gets boxed and you pay an allocation. Generics with value-type constraints avoid this, which is why readonly record struct coordinates work beautifully inside a List<T> but lose their advantage inside an ArrayList. Profile before assuming, but in cases where record structs remain unboxed, the gains are real and measurable.

Pitfalls and best practices worth committing to memory

Adopting record structs in an existing codebase is mostly mechanical, but a few traps catch even experienced Australian teams. Mutable reference-type fields silently undermine the immutability guarantee, large record structs undermine the stack-allocation argument because the runtime spills them onto the heap, and accidental boxing through interfaces erases the value-type advantage in a single line. None of these are reasons to avoid the feature; they are reasons to apply it deliberately.

Common pitfalls to watch for:

• Mutable fields: any field whose type is itself mutable, such as a collection or a span over an array, lets external code change the contents of your "immutable" record struct.
• Over-sized structs: keep record structs small. Past roughly 16 bytes on 32-bit or 24 bytes on 64-bit, the runtime stops favouring stack storage and you lose the main reason to reach for a struct.
• Implicit boxing: avoid assigning record structs to object, ValueTuple wrappers, or interface variables on hot paths.
• Default construction: without an explicit parameterless constructor, default(T) produces a record struct whose fields are all default, which can be a valid state or a meaningless one depending on your domain.

When you keep these rules in mind, record structs become a reliable building block rather than a footgun. Reach for them when you have a small, fixed shape of data that benefits from value semantics, and reach for record classes when you need inheritance, reference identity, or nullability. The C# Corner Annual Conference 2020 sessions showed plenty of Australian teams already putting the feature to work in production.