C# 9 Records — Silent GC Pile-Up from 'with' Expressions

Every non-trivial C# application is filled with objects whose only job is to carry data — API responses, domain events, configuration snapshots, query results. For years, developers wrote class after class, manually implementing Equals, GetHashCode, and ToString just to get predictable, safe data containers. That's hours of ceremony for something that should be a one-liner. C# 9, released with .NET 5 in November 2020, introduced Records to solve exactly this problem.

The core pain records fix is the gap between how we think about data objects and how classes actually behave. When you compare two class instances, C# asks 'are these the same object in memory?' — reference equality. But when you compare two shipping addresses or two money amounts, you want to ask 'do they contain the same values?' — value equality. Before records, achieving this required implementing four or five methods by hand every single time, and one typo in GetHashCode could cause subtle, hard-to-find bugs in collections.

By the end of this article you'll understand exactly what records are, how positional syntax and 'with' expressions work, when to reach for a record instead of a class or struct, and the three mistakes that trip up developers who are new to them. You'll also walk away knowing how to confidently answer the record questions that show up in C# interviews.

What a Record Actually Is (and What It Generates for You)

A record in C# 9 is a reference type — built on a class under the hood — but with a radically different set of defaults baked in by the compiler. When you declare a record, the compiler generates: structural equality (Equals and GetHashCode based on property values), a human-readable ToString, a protected copy constructor, and support for deconstruction. You get all of that for free.

The simplest record uses positional syntax: a single line where you list your properties inside parentheses. The compiler turns those into public init-only properties — meaning they can be set during object initialisation but never mutated afterwards. This immutability-by-default is the point. Records are designed to represent data that doesn't change after it's created.

Think of records as the right tool when your object IS its data. A Money value, an OrderId, a GPS coordinate, a User from an API response — these are records. A ShoppingCart that accumulates items, a DatabaseConnection that opens and closes — those are classes. The distinction is behavioural: records have data and identity through their values; classes have data plus mutable state and behaviour.

using System;

// Positional record syntax — the compiler generates init-only properties,
// a constructor, Equals, GetHashCode, ToString, and Deconstruct automatically.
public record Money(decimal Amount, string Currency);

// You can also use the verbose form if you need custom logic on a property.
public record ProductSku
{
    public string Code { get; init; }  // init-only: set once, never changed
    public string Category { get; init; }

    public ProductSku(string code, string category)
    {
        // Validate in the constructor — records support this just like classes
        if (string.IsNullOrWhiteSpace(code))
            throw new ArgumentException("SKU code cannot be empty.", nameof(code));

        Code = code.ToUpperInvariant(); // normalise on the way in
        Category = category;
    }
}

class Program
{
    static void Main()
    {
        var price = new Money(9.99m, "USD");
        var samePriceAgain = new Money(9.99m, "USD");
        var differentCurrency = new Money(9.99m, "GBP");

        // Value equality — compares property values, not memory addresses
        Console.WriteLine(price == samePriceAgain);      // True
        Console.WriteLine(price == differentCurrency);   // False
        Console.WriteLine(price.Equals(samePriceAgain)); // True

        // Compiler-generated ToString shows all properties
        Console.WriteLine(price); // Money { Amount = 9.99, Currency = USD }

        // Deconstruction — unpack a record into individual variables
        var (amount, currency) = price;
        Console.WriteLine($"{amount} {currency}"); // 9.99 USD

        // Verbose-form record with validation
        var sku = new ProductSku("abc-123", "Electronics");
        Console.WriteLine(sku.Code); // ABC-123  (normalised to uppercase)
    }
}

'with' Expressions: Updating Immutable Records Without the Pain

Immutability sounds great until you need to change one field. With a regular immutable class you'd have to call the constructor again and manually pass every single property — even the ones you're not changing. For a record with eight properties, that's eight arguments just to update one value. Nightmare.

C# 9 introduces the 'with' expression to solve this. It creates a new record instance that is a copy of the original, with only the properties you specify changed. The original is untouched. Under the hood, 'with' calls the compiler-generated protected copy constructor (sometimes called the clone constructor), then applies a set of property initialisers.

This pattern is everywhere in functional programming and is the backbone of state management systems like Redux. In C# it lets you model things like 'apply a discount to this price' or 'mark this order as shipped' without mutating the original object — making your code far easier to reason about, test, and debug. If a bug is reported with a specific order state, you can reproduce it exactly because that state never changed after it was created.

using System;

public record ShippingAddress(
    string RecipientName,
    string Line1,
    string? Line2,
    string City,
    string PostalCode,
    string CountryCode
);

public record Order(
    Guid OrderId,
    string Status,
    ShippingAddress Destination,
    decimal TotalAmount
);

class Program
{
    static void Main()
    {
        var originalAddress = new ShippingAddress(
            RecipientName: "Alice Johnson",
            Line1: "42 Elmwood Drive",
            Line2: null,
            City: "Portland",
            PostalCode: "97201",
            CountryCode: "US"
        );

        var originalOrder = new Order(
            OrderId: Guid.NewGuid(),
            Status: "Pending",
            Destination: originalAddress,
            TotalAmount: 149.99m
        );

        // 'with' creates a brand-new record — originalOrder is NEVER modified
        var dispatchedOrder = originalOrder with { Status = "Dispatched" };

        // Apply a correction to just the postal code — everything else stays
        var correctedAddress = originalAddress with { PostalCode = "97202" };

        // 'with' also works on nested records, but you must replace the whole nested record
        var reRoutedOrder = originalOrder with
        {
            Destination = originalAddress with { City = "Seattle", PostalCode = "98101" }
        };

        Console.WriteLine($"Original  status : {originalOrder.Status}");   // Pending
        Console.WriteLine($"Dispatched status: {dispatchedOrder.Status}"); // Dispatched

        Console.WriteLine($"Same OrderId? {originalOrder.OrderId == dispatchedOrder.OrderId}"); // True
        Console.WriteLine($"Same object?  {ReferenceEquals(originalOrder, dispatchedOrder)}");  // False

        Console.WriteLine($"Original city  : {originalOrder.Destination.City}");    // Portland
        Console.WriteLine($"Re-routed city : {reRoutedOrder.Destination.City}");    // Seattle

        // Value equality compares the full graph of properties
        var duplicate = originalOrder with { };  // identical copy
        Console.WriteLine($"Equal to duplicate? {originalOrder == duplicate}");     // True
    }
}

Records vs Classes vs Structs: Choosing the Right Tool

The question developers ask most often is 'when do I use a record instead of a class?' The honest answer comes down to three things: immutability, equality semantics, and size.

Use a record when your type IS its data — an immutable snapshot where two instances with identical values should be considered the same thing. API DTOs, domain value objects (Money, EmailAddress, DateRange), event sourcing events, command objects, and configuration snapshots are all textbook records.

Use a class when your type has mutable state, behaviour-heavy logic, or identity that's separate from its data. A UserSession, a DatabaseConnection, or a ShoppingCart accumulates state over time — the 'same' cart from a minute ago is still the same cart even if the items changed. That's a class.

Use a struct when you need stack allocation for small, frequently-created value types — think Vector2, RGBA colour, or a cache key. C# 10 introduced record structs if you want value semantics plus records' equality machinery, but for C# 9 the sweet spot is: structs for tiny, perf-critical value types; records for immutable data objects; classes for everything that has mutable state and behaviour.

using System;
using System.Collections.Generic;

// RECORD — value equality, immutable, great for DTOs and value objects
public record EmailAddress(string Value)
{
    // Custom validation in a compact primary constructor body
    public EmailAddress(string value) : this(value)
    {
        if (!value.Contains('@'))
            throw new ArgumentException("Not a valid email address.", nameof(value));
    }
}

// CLASS — reference equality, mutable state, represents a 'thing' with a lifecycle
public class UserSession
{
    public Guid SessionId { get; } = Guid.NewGuid();
    public string UserName { get; set; }  // can change during the session
    public List<string> VisitedPages { get; } = new();

    public UserSession(string userName) => UserName = userName;

    public void NavigateTo(string page) => VisitedPages.Add(page);
}

class Program
{
    static void Main()
    {
        // --- Record behaviour ---
        var email1 = new EmailAddress("alice@example.com");
        var email2 = new EmailAddress("alice@example.com");

        // Same value → considered equal. Perfect for use as dictionary keys.
        Console.WriteLine($"Emails equal: {email1 == email2}"); // True

        var emailLookup = new Dictionary<EmailAddress, string>
        {
            [email1] = "Alice Johnson"
        };
        // email2 works as the lookup key because it has the same value
        Console.WriteLine($"Name: {emailLookup[email2]}"); // Alice Johnson

        // --- Class behaviour ---
        var session1 = new UserSession("alice");
        var session2 = new UserSession("alice");

        // Different objects in memory → NOT equal, even with same data
        Console.WriteLine($"Sessions equal: {session1 == session2}"); // False

        // Classes are designed for mutable, evolving state
        session1.NavigateTo("/dashboard");
        session1.NavigateTo("/orders");
        Console.WriteLine($"Pages visited: {session1.VisitedPages.Count}"); // 2
    }
}

Inheritance and Record Hierarchies: Powerful but with Limits

Records support single-level inheritance, and this is where they really shine for modelling domain events or discriminated-union-style hierarchies. A base record can hold shared properties, and derived records add specifics. The 'with' expression and equality both respect the actual runtime type — a crucial detail that catches people out.

Records cannot inherit from classes (other than object), and classes cannot inherit from records. The inheritance chain must be all records. This keeps the equality contract consistent — you'd get bizarre results if a record's Equals method had to compare itself against an arbitrary class hierarchy.

When you compare two records for equality, the runtime type must match. A base record instance is NOT equal to a derived record instance, even if all the base properties are identical. This is the correct behaviour — they represent different concepts — but it surprises developers who are coming from manually written Equals implementations that check only specific properties.

using System;

// Base record — shared properties for all payment events
public abstract record PaymentEvent(
    Guid PaymentId,
    DateTime OccurredAt,
    decimal Amount
);

// Derived records — each adds its own context
public record PaymentInitiated(
    Guid PaymentId,
    DateTime OccurredAt,
    decimal Amount,
    string PayerEmail          // extra field for this event type
) : PaymentEvent(PaymentId, OccurredAt, Amount);

public record PaymentSucceeded(
    Guid PaymentId,
    DateTime OccurredAt,
    decimal Amount,
    string TransactionReference // extra field for this event type
) : PaymentEvent(PaymentId, OccurredAt, Amount);

public record PaymentFailed(
    Guid PaymentId,
    DateTime OccurredAt,
    decimal Amount,
    string FailureReason
) : PaymentEvent(PaymentId, OccurredAt, Amount);

class Program
{
    static void ProcessEvent(PaymentEvent evt)
    {
        // Pattern matching on records is clean and exhaustive
        var description = evt switch
        {
            PaymentInitiated e  => $"Payment started by {e.PayerEmail}",
            PaymentSucceeded e  => $"Payment confirmed. Ref: {e.TransactionReference}",
            PaymentFailed e     => $"Payment failed: {e.FailureReason}",
            _                   => "Unknown payment event"
        };
        Console.WriteLine($"[{evt.OccurredAt:HH:mm:ss}] ${evt.Amount:F2} — {description}");
    }

    static void Main()
    {
        var paymentId = Guid.NewGuid();
        var now = DateTime.UtcNow;

        var initiated  = new PaymentInitiated(paymentId, now, 49.99m, "bob@example.com");
        var succeeded  = new PaymentSucceeded(paymentId, now.AddSeconds(2), 49.99m, "TXN-8821");
        var failed     = new PaymentFailed(paymentId, now, 49.99m, "Card declined");

        ProcessEvent(initiated);
        ProcessEvent(succeeded);
        ProcessEvent(failed);

        // IMPORTANT: type matters for equality
        // Even though all base properties match, these are DIFFERENT types
        PaymentEvent asBase = initiated;
        var anotherInitiated = new PaymentInitiated(paymentId, now, 49.99m, "bob@example.com");

        Console.WriteLine($"Same type, same values: {initiated == anotherInitiated}"); // True
        // Casting doesn't change what the object IS
        Console.WriteLine($"Base ref == derived:    {asBase == anotherInitiated}");    // True (same type at runtime)
    }
}

Performance Considerations and When to Use Mutable Fallbacks

Records are not free. Every 'with' expression allocates a new object on the heap. The compiler-generated Equals and GetHashCode use reflection-like mechanisms (EqualityComparer.Default) that can box value types. For most applications — API calls, database operations, event streams — these costs are negligible. But in hot paths processing thousands of items per second, records can become a GC bottleneck.

Consider the scenario: a real-time telemetry system processing 10,000 sensor readings per second. Each reading is a record with 12 fields. Every update to a reading uses 'with' to change a single field (e.g., temperature). That's 10,000 record allocations per second just for updates — plus the original records. In less than a minute, you've generated over a million short-lived objects. The Gen0 GC will fire frequently, causing micro-stalls.

The fix is straightforward: use a mutable class for the hot processing loop, then convert to a record at the boundary when you need to persist or send the data. Or use pooled record instances with a reset pattern. Another option: use a record struct (C# 10) which lives on the stack and avoids heap allocation entirely, though you lose inheritance and reference semantics.

Another hidden cost: records with many properties generate large Equals implementations. If you frequently compare records with 20+ fields, the per-comparison cost adds up. Consider using a simplified equality if you only need a subset of fields to match.

using System;
using System.Diagnostics;

// Record with 8 properties — typical for a DTO
public record SensorReading(
    long SensorId,
    double Temperature,
    double Humidity,
    double Pressure,
    DateTime Timestamp,
    string Location,
    string Unit,
    double BatteryLevel
);

// Equivalent mutable class
public class MutableSensorReading
{
    public long SensorId { get; set; }
    public double Temperature { get; set; }
    public double Humidity { get; set; }
    public double Pressure { get; set; }
    public DateTime Timestamp { get; set; }
    public string Location { get; set; }
    public string Unit { get; set; }
    public double BatteryLevel { get; set; }
}

class Program
{
    static void Main()
    {
        const int iterations = 1_000_000;
        var sw = Stopwatch.StartNew();

        // Record with 'with' — each call allocates a new object
        var record = new SensorReading(1, 23.5, 60, 1013, DateTime.UtcNow, "Warehouse-A", "Celsius", 85.0);
        for (int i = 0; i < iterations; i++)
        {
            record = record with { Temperature = 23.5 + i * 0.01 };
        }
        sw.Stop();
        Console.WriteLine($"Record 'with' x {iterations}: {sw.ElapsedMilliseconds} ms");

        // Mutable class — no allocation per update, just property assignment
        var mutable = new MutableSensorReading
        {
            SensorId = 1, Temperature = 23.5, Humidity = 60, Pressure = 1013,
            Timestamp = DateTime.UtcNow, Location = "Warehouse-A", Unit = "Celsius", BatteryLevel = 85.0
        };
        sw.Restart();
        for (int i = 0; i < iterations; i++)
        {
            mutable.Temperature = 23.5 + i * 0.01;
        }
        sw.Stop();
        Console.WriteLine($"Mutable class x {iterations}: {sw.ElapsedMilliseconds} ms");
    }
}

/* Output (typical):
Record 'with' x 1000000: 1850 ms
Mutable class x 1000000: 45 ms
*/

Why Records Break Your Serialization Contracts (And How to Fix It)

Records generate compiler-synthesized properties with init setters. That sounds great for immutability until your JSON deserializer tries to hydrate an object and fails because Newtonsoft.Json doesn't respect init out of the box. The same goes for Dapper, Entity Framework, or any tool that calls public setters. Production logs fill with 'Property setter not found' exceptions. The fix: use System.Text.Json (settings.JsonSerializerOptions.IncludeFields = true) or stick to positional records where the compiler generates a Deconstruct method that plays nicely with deserializers. If you need legacy serializer support, don't use init without checking the serializer's compatibility matrix first. The reason this matters: silent data loss from half-initialized objects is far worse than a compile error.

// io.thecodeforge
using System.Text.Json;

public record Product(string Id, decimal Price);

public class OrderService
{
    public static Product DeserializeProduct(string json)
    {
        var options = new JsonSerializerOptions
        {
            PropertyNameCaseInsensitive = true
        };
        return JsonSerializer.Deserialize<Product>(json, options);
    }
}

// Test with: {"Id": "PROD-001", "Price": 29.99}
// Output: Product { Id = PROD-001, Price = 29.99 }

The Hidden Cost of 'record' on Hot Paths: Stack Allocations or Heap Pressure?

Developers pick records thinking they get class-like semantics with less boilerplate. But record class is a reference type — each allocation goes on the heap. In tight loops (game loops, high-frequency trading, or real-time processing), every new on a record creates GC pressure. record struct fixes this: stack allocation, no GC overhead, but you lose inheritance. The decision matrix is straightforward: if your record lives longer than a single method call, use record class. If it's ephemeral — immediate computation then discard — use record struct. The readonly record struct modifier eliminates defensive copies in method parameters. Measure allocation with BenchmarkDotNet before optimizing. Do not guess. The reason: a 5% GC pause in a trading system costs real money; a 5% GC pause in an admin panel is invisible.

// io.thecodeforge
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

public readonly record struct PointRecordStruct(int X, int Y);
public record class PointRecordClass(int X, int Y);

public class RecordBenchmark
{
    [Benchmark]
    public int StructAllocation()
    {
        var p = new PointRecordStruct(42, 99);
        return p.X + p.Y; // stack allocated, zero GC
    }

    [Benchmark]
    public int ClassAllocation()
    {
        var p = new PointRecordClass(42, 99);
        return p.X + p.Y; // heap allocated, GC pressure
    }
}

Record Structs in C# 10+

C# 10 introduced record structs, combining value-type semantics with the immutability and syntactic convenience of records. Unlike record classes (reference types), record structs are value types, meaning they are copied on assignment and stored on the stack (or inline in other objects). This eliminates heap allocation and reduces GC pressure, making them ideal for high-performance scenarios where immutability is desired but heap overhead is unacceptable.

To declare a record struct, use readonly record struct for full immutability or record struct for mutable fields (though the latter is rarely used). For example:

``csharp public readonly record struct Point(double X, double Y); ``

This generates a value type with positional construction, ToString(), Equals(), GetHashCode(), Deconstruct, and ==/!= operators. The readonly modifier ensures all fields are readonly, enforcing immutability.

Record structs support with expressions, but unlike class records, they do not generate a copy constructor; instead, the compiler creates a new instance by copying and modifying fields. This is efficient because value types are small and stack-allocated.

However, record structs have limitations: they cannot inherit from other record structs (structs cannot inherit), and they should be kept small (typically under 16-24 bytes) to avoid excessive copying. For larger immutable data, record classes remain the better choice.

Performance-wise, record structs eliminate heap allocations entirely. In tight loops, using a record struct instead of a record class can reduce GC collections by orders of magnitude. For example, processing 1 million points as record structs avoids 1 million heap allocations, whereas record classes would trigger frequent GC pauses.

public readonly record struct Point(double X, double Y);

public class Processor
{
    public double CalculateDistance(Point p1, Point p2)
    {
        double dx = p1.X - p2.X;
        double dy = p1.Y - p2.Y;
        return Math.Sqrt(dx * dx + dy * dy);
    }
}

// Usage
var points = new Point[1000000];
// Populate points...
// No heap allocations for Point instances

With Expressions for Non-Destructive Mutation

with expressions are a hallmark of records, enabling non-destructive mutation: creating a new instance with modified properties while leaving the original unchanged. This is syntactic sugar over the compiler-generated copy constructor (for class records) or field-wise copy (for struct records).

Under the hood, with expressions call a protected copy constructor that performs a shallow copy of the record's backing fields, then applies the specified property changes. For example:

``csharp var original = new Person("Alice", 30); var updated = original with { Age = 31 }; ``

This creates a new Person instance with Name copied from original and Age set to 31. The original remains unchanged.

For record structs, with expressions do not use a copy constructor; instead, the compiler generates code that copies the struct and modifies the specified fields. This is more efficient for value types.

Performance considerations: Each with expression on a record class allocates a new object on the heap, increasing GC pressure. In hot paths, this can cause significant overhead. For example, updating a single field in a loop of 1 million iterations creates 1 million heap allocations. Mitigation strategies include: - Using mutable fallbacks (e.g., regular classes) for high-frequency updates. - Using record structs to avoid heap allocation entirely. - Batching updates to reduce the number of with calls.

with expressions also work with anonymous types and can be chained, but each chain step creates an intermediate allocation. For complex updates, consider using a builder pattern or mutable DTOs.

Finally, with expressions respect inheritance: they preserve the runtime type of the record, so if you have a derived record, the new instance will be of the derived type.

public record Person(string Name, int Age);

public class Demo
{
    public void Test()
    {
        var alice = new Person("Alice", 30);
        var olderAlice = alice with { Age = 31 };
        Console.WriteLine(alice);    // Person { Name = Alice, Age = 30 }
        Console.WriteLine(olderAlice); // Person { Name = Alice, Age = 31 }
    }
}

Records vs Classes vs Structs: Decision Guide

Choosing between records, classes, and structs depends on your data's size, mutability needs, and performance requirements. Below is a decision guide with performance data.

Records (class): Reference type, immutable by default, value equality. Best for DTOs, domain events, and data that benefits from structural equality. Heap-allocated; each with expression creates a new object. Allocation overhead: ~32 bytes + fields.

Classes: Reference type, mutable by default, reference equality. Best for long-lived objects, services, and entities with identity. Heap-allocated; mutations do not allocate new objects. Allocation overhead: ~24 bytes + fields.

Structs: Value type, mutable or immutable, value equality. Best for small, frequently created data (e.g., coordinates, colors). Stack-allocated (or inline); no heap allocation. Copy overhead on assignment. Limit size to <16-24 bytes to avoid performance degradation.

Record Structs: Value type, immutable (if readonly), value equality. Combines struct performance with record syntax. Ideal for small immutable data in hot paths.

Performance Data (approximate, per 1 million operations): - Class allocation: 1 million objects, ~24 MB heap, GC gen0 collections ~10-20. - Record class with: 1 million objects, ~32 MB heap, GC gen0 collections ~15-25. - Struct copy: 1 million copies, 0 heap, 0 GC. - Record struct with: 1 million copies, 0 heap, 0 GC (if small).

Decision Matrix: | Scenario | Recommendation | |----------|----------------| | Immutable, value equality, heap OK | Record class | | Mutable, reference equality | Class | | Small, frequent creation, immutable | Record struct | | Small, frequent creation, mutable | Mutable struct (careful) | | Large data (>24 bytes) | Class or record class | | Hot path, no allocations allowed | Record struct or mutable struct |

In practice, profile your application. For most business applications, records are fine. For high-performance computing, favor structs.

// Record class: good for DTOs
public record ProductDto(int Id, string Name, decimal Price);

// Class: good for services
public class OrderService { ... }

// Record struct: good for coordinates
public readonly record struct Point(double X, double Y);

// Struct: good for small mutable data (use with caution)
public struct MutablePoint { public double X, Y; }