What is a record struct in C# 10, and how does it differ from a record class and a plain struct? Explain readonly record struct, the mutability default, generated equality versus ValueType.Equals, with expressions on structs, the default value problem, and when a record struct is the right choice.

How I would answer this in an interview

A record struct (C# 10) is a value type with record features generated: value equality via IEquatable<T>, ==/!=, ToString, Deconstruct and with. It combines the no-allocation benefit of structs with fast, correct generated equality. I'd compare it with record classes and plain structs, explain readonly record struct, the mutability default, with, the default value problem, and when it's the right choice.

1. Declaring

public record struct Point(int X, int Y);                 // mutable positional properties (get; set;)
public readonly record struct OrderId(Guid Value);        // immutable (get; init;), readonly struct
public readonly record struct Money(decimal Amount, string Currency)
{
    public static Money Aud(decimal amount) => new(amount, "AUD");
}

2. Versus record class and plain struct

3. readonly record struct and the mutability default

A plain record struct's positional properties are mutable ({ get; set; }) — chosen for consistency with tuples and struct conventions. That reintroduces mutable-struct bugs (mutating copies; changing hash codes of dictionary keys). readonly record struct makes positional properties init-only and the struct readonly, which:

• guarantees immutability,
• avoids defensive copies when passed by in or stored in readonly fields,
• makes it safe as a dictionary key.

My default is readonly record struct.

4. Generated equality vs ValueType.Equals

A plain struct's Equals(object) is ValueType.Equals: it boxes the argument and, if the struct contains references or padding, uses reflection to compare fields — slow; GetHashCode may only hash the first field, causing poor distribution. A record struct generates strongly typed Equals(T) using EqualityComparer<TField>.Default per field and a full GetHashCode — fast, no boxing, good hashing. That's the main reason to prefer record structs (or hand-written IEquatable<T>) for value types used in collections.

5. with expressions on structs

var p2 = p1 with { Y = 10 };   // copies the struct (by value), then sets Y

For structs, with is just a value copy plus property sets — cheap, no allocation. Since C# 10 with works on any struct, not just record structs.

6. The default value problem

default(OrderId) is OrderId(Guid.Empty) and default(Money) is Money(0, null) — created without running any constructor: from default, array elements, uninitialised fields, missing JSON properties, EF Core key sentinels. Positional parameters can't prevent it. Mitigations:

• Treat the zero value as valid (e.g. Money.Zero), or provide IsDefault/IsEmpty checks.
• Validate at boundaries (API input, factory methods).
• For strongly typed IDs, configure EF Core sentinels/value converters and reject Guid.Empty in validation.
• Avoid reference-type fields that must be non-null, or handle null (e.g. Currency ?? "AUD").

7. When a record struct is the right choice

• Strongly typed IDs (CustomerId, OrderId) — no allocation, value equality, prevents mixing IDs.
• Small value objects (≤ ~16–32 bytes): coordinates, DateRange of DateOnlys, Money (decimal + short code).
• Composite dictionary keys in hot paths ((Region, Year) with names).
• High-volume data in arrays/spans (telemetry readings).

Not a fit: large data (copy cost), types needing inheritance, types frequently boxed (interfaces/object), or values whose default state is dangerous and can't be handled.

8. A production example

An order system passed IDs as raw Guids, and a bug passed a customerId where an orderId was expected — the query returned nothing and a refund silently failed. Introducing readonly record struct OrderId(Guid Value) and CustomerId(Guid Value), with EF Core value converters and System.Text.Json converters, made such mix-ups compile errors with no allocation overhead. We added a validation rule rejecting default IDs at API boundaries.