Records are reference types with value equality and init-only properties, generated by the compiler.
Use records for immutable data snapshots—DTOs, value objects, domain events.
'with' expressions create shallow copies; nested mutable objects are shared, not cloned.
Equality checks include runtime type (EqualityContract) — derived records never equal base records.
Performance trap: every 'with' allocates a new object — high-frequency use causes GC pressure.
Biggest mistake: expecting deep immutability when a property holds List or other mutable classes.
Plain-English First
Imagine you're filling out a form at the doctor's office. Once it's stamped and filed, nobody is allowed to scribble over your name or date of birth — the record is sealed. If they need to update something, they make a fresh copy of the form with just that one field changed. That's exactly what a C# Record is: a sealed snapshot of data. Two forms with identical information are considered the same record, even if they're physically two different pieces of paper — unlike a regular class object, which is only 'equal' if it's literally the same piece of paper.
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.
BasicRecordDemo.csCSHARP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
usingSystem;
// Positional record syntax — the compiler generates init-only properties,// a constructor, Equals, GetHashCode, ToString, and Deconstruct automatically.public record Money(decimalAmount, stringCurrency);
// 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 changedpublicstringCategory { get; init; }
publicProductSku(string code, string category)
{
// Validate in the constructor — records support this just like classesif (string.IsNullOrWhiteSpace(code))
thrownewArgumentException("SKU code cannot be empty.", nameof(code));
Code = code.ToUpperInvariant(); // normalise on the way inCategory = category;
}
}
classProgram
{
staticvoidMain()
{
var price = newMoney(9.99m, "USD");
var samePriceAgain = newMoney(9.99m, "USD");
var differentCurrency = newMoney(9.99m, "GBP");
// Value equality — compares property values, not memory addressesConsole.WriteLine(price == samePriceAgain); // TrueConsole.WriteLine(price == differentCurrency); // FalseConsole.WriteLine(price.Equals(samePriceAgain)); // True// Compiler-generated ToString shows all propertiesConsole.WriteLine(price); // Money { Amount = 9.99, Currency = USD }// Deconstruction — unpack a record into individual variablesvar (amount, currency) = price;
Console.WriteLine($"{amount} {currency}"); // 9.99 USD// Verbose-form record with validationvar sku = newProductSku("abc-123", "Electronics");
Console.WriteLine(sku.Code); // ABC-123 (normalised to uppercase)
}
}
Output
True
False
True
Money { Amount = 9.99, Currency = USD }
9.99 USD
ABC-123
What the Compiler Actually Generates:
Run 'dotnet build' then open the assembly in SharpLab.io (set output to C#). You'll see the compiler emits a full Equals(Money? other), GetHashCode(), ToString(), and a protected copy constructor called 'Clone'. Understanding this makes records far less magical and helps you debug edge cases.
Production Insight
Records are heap-allocated — if you create millions in a hot path, GC will hurt.
The compiler-generated Equals uses EqualityComparer<T>.Default, which boxes value types.
Rule: profile allocation rates before committing to records in critical paths.
Key Takeaway
Records are reference types with value equality.
The compiler generates Equals, GetHashCode, ToString, and a copy constructor.
Use them for data snapshots, not for mutable, behaviour-rich objects.
'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.
WithExpressionDemo.csCSHARP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
usingSystem;
public record ShippingAddress(
stringRecipientName,
stringLine1,
string? Line2,
stringCity,
stringPostalCode,
stringCountryCode
);
public record Order(
GuidOrderId,
stringStatus,
ShippingAddressDestination,
decimalTotalAmount
);
classProgram
{
staticvoidMain()
{
var originalAddress = newShippingAddress(
RecipientName: "Alice Johnson",
Line1: "42 Elmwood Drive",
Line2: null,
City: "Portland",
PostalCode: "97201",
CountryCode: "US"
);
var originalOrder = newOrder(
OrderId: Guid.NewGuid(),
Status: "Pending",
Destination: originalAddress,
TotalAmount: 149.99m
);
// 'with' creates a brand-new record — originalOrder is NEVER modifiedvar dispatchedOrder = originalOrder with { Status = "Dispatched" };
// Apply a correction to just the postal code — everything else staysvar correctedAddress = originalAddress with { PostalCode = "97202" };
// 'with' also works on nested records, but you must replace the whole nested recordvar reRoutedOrder = originalOrder with
{
Destination = originalAddress with { City = "Seattle", PostalCode = "98101" }
};
Console.WriteLine($"Original status : {originalOrder.Status}"); // PendingConsole.WriteLine($"Dispatched status: {dispatchedOrder.Status}"); // DispatchedConsole.WriteLine($"SameOrderId? {originalOrder.OrderId == dispatchedOrder.OrderId}"); // TrueConsole.WriteLine($"Same object? {ReferenceEquals(originalOrder, dispatchedOrder)}"); // FalseConsole.WriteLine($"Original city : {originalOrder.Destination.City}"); // PortlandConsole.WriteLine($"Re-routed city : {reRoutedOrder.Destination.City}"); // Seattle// Value equality compares the full graph of properties
var duplicate = originalOrder with { }; // identical copyConsole.WriteLine($"Equal to duplicate? {originalOrder == duplicate}"); // True
}
}
Output
Original status : Pending
Dispatched status: Dispatched
Same OrderId? True
Same object? False
Original city : Portland
Re-routed city : Seattle
Equal to duplicate? True
Watch Out: 'with' Is Shallow for Nested Mutable Objects
If a record property is a mutable reference type (like a List<T> or a class), 'with' copies the reference, not the object. Both the original and the copy point to the same list. To stay truly immutable, use ImmutableList<T> from System.Collections.Immutable, or use record types for all nested data as well.
Production Insight
The copy constructor is generated but not virtual — inheritance chains still use a protected memberwise clone.
Nested records require explicit 'with' for each level — no deep copy.
Rule: if you need deep immutability, ensure all property types are themselves immutable.
Key Takeaway
'with' creates a new record via the copy constructor — the original is never mutated.
Shallow copy means mutable reference properties (e.g., List<T>) are shared.
Always check nested property types for mutability when using 'with'.
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.
RecordVsClassComparison.csCSHARP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
usingSystem;
usingSystem.Collections.Generic;
// RECORD — value equality, immutable, great for DTOs and value objectspublic record EmailAddress(stringValue)
{
// Custom validation in a compact primary constructor bodypublicEmailAddress(string value) : this(value)
{
if (!value.Contains('@'))
thrownewArgumentException("Not a valid email address.", nameof(value));
}
}
// CLASS — reference equality, mutable state, represents a 'thing' with a lifecyclepublicclassUserSession
{
publicGuidSessionId { get; } = Guid.NewGuid();
public string UserName { get; set; } // can change during the sessionpublicList<string> VisitedPages { get; } = new();
publicUserSession(string userName) => UserName = userName;
publicvoidNavigateTo(string page) => VisitedPages.Add(page);
}
classProgram
{
staticvoidMain()
{
// --- Record behaviour ---var email1 = newEmailAddress("alice@example.com");
var email2 = newEmailAddress("alice@example.com");
// Same value → considered equal. Perfect for use as dictionary keys.Console.WriteLine($"Emails equal: {email1 == email2}"); // Truevar emailLookup = newDictionary<EmailAddress, string>
{
[email1] = "Alice Johnson"
};
// email2 works as the lookup key because it has the same valueConsole.WriteLine($"Name: {emailLookup[email2]}"); // Alice Johnson// --- Class behaviour ---var session1 = newUserSession("alice");
var session2 = newUserSession("alice");
// Different objects in memory → NOT equal, even with same dataConsole.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
}
}
Output
Emails equal: True
Name: Alice Johnson
Sessions equal: False
Pages visited: 2
Pro Tip: Records as Dictionary Keys
Because records override GetHashCode based on their property values, they work perfectly and safely as dictionary keys or in HashSets — unlike custom classes where you'd have to manually implement GetHashCode to avoid collisions. This alone can save you from a whole category of subtle bugs.
Production Insight
Choosing a class over a record can save millions of allocations — but you lose value equality.
Structs avoid heap allocation but can cause expensive copying in collections.
Rule: benchmark your actual use case — don't assume struct is always faster.
Key Takeaway
Records for data, classes for behaviour, structs for tiny values.
Value equality makes records safe dictionary keys without extra code.
Benchmark allocations — records are not free.
Decision: Record, Class, or Struct?
IfObject is an immutable data snapshot, value equality intended
→
UseUse Record
IfObject has mutable state, behaviour, or lifecycle identity
→
UseUse Class
IfObject is small (<=16 bytes), performance-critical, no inheritance needed
→
UseUse Struct
IfObject needs value semantics AND performance of a value type (C# 10+)
→
UseUse Record Struct
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.
RecordInheritanceDemo.csCSHARP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
usingSystem;
// Base record — shared properties for all payment eventspublicabstract record PaymentEvent(
GuidPaymentId,
DateTimeOccurredAt,
decimalAmount
);
// Derived records — each adds its own contextpublic record PaymentInitiated(
GuidPaymentId,
DateTimeOccurredAt,
decimalAmount,
string PayerEmail// extra field for this event type
) : PaymentEvent(PaymentId, OccurredAt, Amount);
public record PaymentSucceeded(
GuidPaymentId,
DateTimeOccurredAt,
decimalAmount,
string TransactionReference// extra field for this event type
) : PaymentEvent(PaymentId, OccurredAt, Amount);
public record PaymentFailed(
GuidPaymentId,
DateTimeOccurredAt,
decimalAmount,
stringFailureReason
) : PaymentEvent(PaymentId, OccurredAt, Amount);
classProgram
{
staticvoidProcessEvent(PaymentEvent evt)
{
// Pattern matching on records is clean and exhaustivevar 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}");
}
staticvoidMain()
{
var paymentId = Guid.NewGuid();
var now = DateTime.UtcNow;
var initiated = newPaymentInitiated(paymentId, now, 49.99m, "bob@example.com");
var succeeded = newPaymentSucceeded(paymentId, now.AddSeconds(2), 49.99m, "TXN-8821");
var failed = newPaymentFailed(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 typesPaymentEvent asBase = initiated;
var anotherInitiated = newPaymentInitiated(paymentId, now, 49.99m, "bob@example.com");
Console.WriteLine($"Same type, same values: {initiated == anotherInitiated}"); // True// Casting doesn't change what the object ISConsole.WriteLine($"Base ref == derived: {asBase == anotherInitiated}"); // True (same type at runtime)
}
}
Output
[14:22:08] $49.99 — Payment started by bob@example.com
Record hierarchies combined with switch expressions are essentially C#'s version of discriminated unions — a concept from F# and Haskell. Interviewers love asking about this pattern. Mentioning it shows you understand the design intent, not just the syntax.
Production Insight
If payment events are stored in a single table, you'll need a discriminator column for the derived type.
Combining record hierarchies with serialization (JSON) requires type discriminators.
Rule: plan the persistence model before designing record hierarchies.
Key Takeaway
Records can only inherit from other records — no class mixing.
Equality checks runtime type: a base and derived record with same base values are NOT equal.
Use record hierarchies with pattern matching for clean domain event handling.
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<T>.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.
PerformanceComparison.csCSHARP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
usingSystem;
usingSystem.Diagnostics;
// Record with 8 properties — typical for a DTOpublic record SensorReading(
longSensorId,
doubleTemperature,
doubleHumidity,
doublePressure,
DateTimeTimestamp,
stringLocation,
stringUnit,
doubleBatteryLevel
);
// Equivalent mutable classpublicclassMutableSensorReading
{
publiclongSensorId { get; set; }
publicdoubleTemperature { get; set; }
publicdoubleHumidity { get; set; }
publicdoublePressure { get; set; }
publicDateTimeTimestamp { get; set; }
publicstringLocation { get; set; }
publicstringUnit { get; set; }
publicdoubleBatteryLevel { get; set; }
}
classProgram
{
staticvoidMain()
{
constint iterations = 1_000_000;
var sw = Stopwatch.StartNew();
// Record with 'with' — each call allocates a new objectvar record = newSensorReading(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 assignmentvar mutable = newMutableSensorReading
{
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
Mutableclass x 1000000: 45 ms
*/
Output
Record 'with' x 1000000: 1850 ms
Mutable class x 1000000: 45 ms
The Cost of Immutability
Record 'with' expression always creates a new object on the heap.
The copy constructor copies all fields, even if only one changes.
High-frequency use (thousands/sec) can overwhelm the GC.
Mutable classes reuse the same memory — no allocation for new state.
Strategy: use mutable types in hot paths, convert to records at boundaries.
Production Insight
In real-time telemetry, switching from records to mutable classes reduced GC pauses from 200ms to under 5ms.
The allocation rate dropped from 3 GB/minute to practically zero.
Rule: profile with dotnet-counters before optimizing — don't guess.
Key Takeaway
Records are not free — each 'with' allocates.
Use mutable classes in hot paths; convert to records at system boundaries.
Profile allocation rates with dotnet-counters to make data-driven decisions.
● Production incidentPOST-MORTEMseverity: high
The Silent GC Pile-Up: 300 Orders Created per Second
Symptom
After deploying a new order pipeline, Gen2 GC collections jumped from near zero to multiple per minute. Latency spiked from 50ms to over 12 seconds during GC. CPU usage was low but throughput collapsed.
Assumption
Records are lightweight value objects — the team assumed the compiler-generated code was efficient enough for high-frequency use. They used 'with' expressions to update order status in a tight loop, creating thousands of intermediate record instances per second.
Root cause
Each 'with' expression allocates a new record on the heap. In the payment pipeline, every incoming order went through 8 status transitions (Pending → Validating → Authorizing → Capturing → Captured), each creating a new record via 'with'. At 300 orders/sec, that's 2,400 allocations per second just for the order status — plus copies of nested record fields. The Gen2 heap grew rapidly, triggering frequent full GCs.
Fix
Replaced the record-based status transitions with an enum field on a single mutable class for the hot path. Only the final committed order state was stored as a record for persistence. This reduced allocations by over 95% and eliminated the GC latency.
Key lesson
Every 'with' expression allocates a new object — do not use records in tight, high-frequency loops.
Instrument allocation rates with dotnet-counters before assuming record overhead is negligible.
Reserve records for boundary snapshots (API responses, events) — never for intermediate state in a hot path.
Production debug guideSymptom → Action guide for the three most common record-related issues4 entries
Symptom · 01
Two record instances with identical values are not equal when using == or Equals
→
Fix
Check if the records are different derived types, even if the base properties match. The generated EqualityContract includes the runtime type. If you need cross-type comparison, write a custom method that extracts shared properties.
Symptom · 02
A 'with' expression unexpectedly modifies data in the original record
→
Fix
Inspect property types for mutable reference types (List<T>, Dictionary, custom classes). 'with' performs a shallow copy — the new record shares the same mutable object. Replace with ImmutableList<T> or defensively copy the property before assignment.
Symptom · 03
GC pressure and high allocation rate after switching to records
→
Fix
Use dotnet-counters to monitor 'gen-2-gc-count' and 'alloc-rate'. If allocation rate exceeds 1 GB/s per core, identify 'with' usage in hot paths. Either cache intermediate states in a mutable class or use pooled record instances with a factory.
Symptom · 04
Record serialization (JSON/XML) includes unexpected fields or fails
→
Fix
Records generate a <Clone>$() method and an EqualityContract property. This can confuse serializers. Use [JsonIgnore] on the EqualityContract if needed, or switch to source generators for JSON serialization in .NET 6+.
★ Record Debugging Cheat SheetQuick commands and actions for diagnosing record-related production issues
High GC allocation rate from records−
Immediate action
Stop the hot path process and capture a memory dump.
Console.WriteLine(original.Items.Count); // Check if original changed
Fix now
Replace List<T> with ImmutableList<T> or manually copy the list in a custom method.
C# 9 Records vs Classes vs Structs
Feature / Aspect
Record (C# 9)
Class
Struct
Memory allocation
Heap (reference type)
Heap (reference type)
Stack (value type)
Default equality
Value (property-by-property)
Reference (same object?)
Value (field-by-field)
Immutability
Init-only by default
Mutable by default
Mutable by default
'with' expression
Built-in, compiler-generated
Not supported natively
Supported in record struct (C# 10)
ToString output
Auto: Type { Prop = val, ... }
Type name only (needs override)
Type name only (needs override)
Inheritance
Records only, no classes
Full class hierarchy
No inheritance allowed
Best for
DTOs, value objects, events
Stateful, behaviour-rich objects
Tiny, perf-critical value types
Null in equality
Null-safe (generated code)
Null handling is manual
Cannot be null (non-nullable)
Deconstruction
Auto-generated for positional
Must implement manually
Must implement manually
Key takeaways
1
Records use value equality by default
two record instances with identical property values ARE equal, making them safe dictionary keys and reliable in collections without any extra code.
2
The 'with' expression creates a shallow copy with specified properties changed
the original record is never mutated, but nested mutable reference types (like List<T>) are still shared between the original and the copy.
3
Choose records for immutable data snapshots (DTOs, value objects, domain events); choose classes for objects with evolving state and identity that's separate from their data.
4
Record inheritance respects runtime types in equality
a base record reference and a derived record instance with matching base properties are equal ONLY if they're the same runtime type, enforced via a generated EqualityContract property.
5
Profile allocation rates before using records in hot paths
each 'with' expression allocates a new object, and high-frequency use can cause GC latency spikes.
Common mistakes to avoid
3 patterns
×
Treating 'init-only' as 'truly immutable' when properties hold mutable reference types
Symptom
A record property is a List<string>, and after construction, list.Add('surprise') changes the state. The record doesn't own an immutable list, it holds a reference to a mutable one.
Fix
Use ImmutableList<T> from System.Collections.Immutable, or replace List<T> with a readonly wrapper like ReadOnlyCollection<T>. Alternatively, always copy the list when assigning.
×
Expecting a base record and a derived record to be equal when their base properties match
Symptom
PaymentInitiated and PaymentSucceeded share the same PaymentId, Amount and OccurredAt, but equality returns false. Equals checks EqualityContract (the runtime type) first.
Fix
Compare only the specific type you intend. If you need cross-type comparison, extract shared properties into a method and compare those explicitly.
×
Using records for objects that need to change frequently in a hot path
Symptom
Every 'with' expression allocates a new object on the heap. Thousands of state updates per second cause GC pressure and latency spikes.
Fix
For high-frequency mutable state, use a class or a mutable struct. Reserve records for data that genuinely doesn't change after creation — like boundary snapshots.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
What is the difference between a record and a class in C# 9, and can you...
Q02SENIOR
How does the 'with' expression work under the hood — what does the compi...
Q03SENIOR
If you have a base record and a derived record with identical values in ...
Q01 of 03SENIOR
What is the difference between a record and a class in C# 9, and can you give a concrete example of when you'd choose each one?
ANSWER
Records are reference types with value equality, immutable init-only properties by default, and compiler-generated Equals/GetHashCode/ToString/Deconstruct. Classes are reference types with reference equality, mutable properties by default, and minimal compiler-generated members. Use a record for an EmailAddress (value equality matters, immutable) and a class for a UserSession (mutable state, identity independent of data).
Q02 of 03SENIOR
How does the 'with' expression work under the hood — what does the compiler actually generate, and what are its limitations with nested mutable objects?
ANSWER
The compiler generates a protected copy constructor (commonly named <Clone>$). The 'with' expression calls this constructor to create a shallow copy of the record, then sets the specified properties using init-only setters. The limitation: if a property is a mutable reference type (e.g., List<T>), the copy shares the same object instance — both original and copy point to the same list. Modifying the list through one reference affects the other. To avoid this, use immutable types (ImmutableList<T>) or manually deep-copy the nested object in a custom method.
Q03 of 03SENIOR
If you have a base record and a derived record with identical values in the base properties, will they be equal? Why or why not — and what is EqualityContract?
ANSWER
No, they will not be equal. The compiler generates a virtual property called EqualityContract that returns the runtime type of the record. The generated Equals method checks EqualityContract first — if the runtime types differ, it returns false without comparing any other properties. This ensures that a PaymentInitiated and PaymentSucceeded with the same PaymentId, Amount, and Timestamp are considered different. EqualityContract is a property of type Type that the compiler adds to every record.
01
What is the difference between a record and a class in C# 9, and can you give a concrete example of when you'd choose each one?
SENIOR
02
How does the 'with' expression work under the hood — what does the compiler actually generate, and what are its limitations with nested mutable objects?
SENIOR
03
If you have a base record and a derived record with identical values in the base properties, will they be equal? Why or why not — and what is EqualityContract?
SENIOR
FAQ · 5 QUESTIONS
Frequently Asked Questions
01
Are C# records immutable?
Positional records use init-only properties, which means they can't be reassigned after the object is constructed — but this isn't the same as deep immutability. If a property holds a mutable type like List<T>, the list contents can still be changed. For true immutability, all property types must also be immutable.
Was this helpful?
02
Can a record inherit from a class in C# 9?
No. Records can only inherit from other records (or from object implicitly). A class cannot inherit from a record either. This restriction exists to keep the equality contract consistent — mixing class and record hierarchies would make value equality unpredictable.
Was this helpful?
03
Is a record a value type or a reference type in C# 9?
A record in C# 9 is a reference type — it's allocated on the heap and passed by reference, just like a class. It behaves like a value type in terms of equality (comparing by property values), but it IS a reference type. C# 10 introduced 'record struct' if you need value-type semantics with record features.
Was this helpful?
04
Does swapping from classes to records automatically improve performance?
Generally no — records allocate on the heap just like classes, and their 'with' expressions add extra allocations. Performance gains come only if you previously implemented custom Equals/GetHashCode incorrectly or inefficiently. The main benefit of records is correctness (value equality) and reduced boilerplate, not raw speed.
Was this helpful?
05
Can I use records with Entity Framework Core?
Yes, EF Core supports records as entity types, but there are caveats. Because records are immutable by default, EF Core cannot proxy them for lazy loading or change tracking. You must use fully constructed objects and disable lazy loading. Consider using a mutable class for the domain model and mapping to records for DTOs.