Records and immutability

A record is a type whose identity is its data. One line declares it:

public record Book(string Title, int Year);

From that, the compiler generates a constructor, init-only properties Title and Year, a Deconstruct method, value-based Equals/GetHashCode and ==/!= over every field, and a readable ToString(). record alone means a reference type (record class); record struct gives the same conveniences on a value type, with one difference: a positional record struct gets ordinary settable properties, and only readonly record struct makes them init-only.

1public record Book(string Title, int Year);2 3public static class Solution4{5    public static string Describe()6    {7        var a = new Book("Dune", 1965);8        var b = new Book("Dune", 1965);9        var c = a with { Year = 1966 };10        return $"{a} | a==b {a == b} | same object {ReferenceEquals(a, b)} | {c} | a unchanged {a.Year}";11    }12}

a and b are two separate objects (ReferenceEquals is false), yet == is true, because records compare their data. Compare that with the plain class in the previous lesson, where two new Point(1, 2) were never equal.

Changing a record means making a new one

The properties are init-only, so a.Year = 1966 does not compile. A with-expression copies the record and changes the listed properties on the copy:

var c = a with { Year = 1966 };

a is untouched. This is called non-destructive mutation, and it is what makes records comfortable to share between threads or keep as history: nobody can change a version you are holding.

Immutable is only as deep as the fields

with copies each field as it is. For a value it copies the value; for a reference it copies the reference. A record that holds a List<T> therefore shares that list with every copy made from it.

1public record Team(string Name, List<string> Members);2 3public static class Solution4{5    public static string Describe()6    {7        var original = new Team("core", new List<string> { "Ana" });8        var copy = original with { Name = "core-2" };9        copy.Members.Add("Luka");10 11        var twin = new Team("core", new List<string> { "Ana", "Luka" });12        return $"original members={string.Join(",", original.Members)} | " +13               $"original==twin {original == twin} | {original}";14    }15}

Adding to copy.Members changed original.Members, because there was only ever one list. The same field also explains the equality result: the generated Equals compares the List field with the list's own Equals, which is reference equality, so two teams with the same member names are still unequal. And the generated ToString just prints the list's type name.

To keep a record genuinely immutable, give it immutable members (ImmutableList<T>, or an IReadOnlyList<T> that you never cast back) and build a new collection whenever a with-expression changes it.

Common mistakes

• Assuming with deep-copies. Shown above: collections and other reference-type members are shared between the original and the copy.
• Expecting a record with a list to compare by contents. Generated equality uses each member's own Equals; for List<T> that is reference equality. Override Equals(Team? other) and GetHashCode if you need sequence comparison.
• Declaring set instead of init on a record property. It compiles, but a record you can mutate can change its hash code while it is a dictionary key, the problem the previous lesson showed.