How do tuples work in C#? Explain System.ValueTuple versus System.Tuple, element names and why they disappear at run time, tuple equality, mutability, performance, serialisation pitfalls, and when you should use a record instead.

How I would answer this in an interview

C# tuples ((int Id, string Name)) are syntax over System.ValueTuple<...> — mutable structs with fields Item1, Item2, ... The element names are compile-time sugar that disappear at run time. Tuples are great for private, local multi-value results; for anything public, serialised or long-lived, I use a record. I'd cover ValueTuple vs the old System.Tuple, names, equality, mutability, performance and serialisation pitfalls.

1. System.ValueTuple vs System.Tuple

2. Syntax and element names

(int Count, decimal Total) Summarise(IEnumerable<Order> orders)
{
    var list = orders.ToList();
    return (list.Count, list.Sum(o => o.Total));
}

var (count, total) = Summarise(orders);         // deconstruction
var s = Summarise(orders);
Console.WriteLine(s.Total);                      // named element
Console.WriteLine(s.Item2);                      // same field

var inferred = (order.Id, order.Total);          // names inferred: inferred.Id, inferred.Total (C# 7.1)

Why names disappear at run time

The runtime type is just ValueTuple<int, decimal> with fields Item1, Item2. Names are stored in a [TupleElementNames] attribute on the method return, parameter, field or property, used only by the compiler. Consequences:

• Reflection sees Item1, Item2.
• Serialisers (System.Text.Json serialises... nothing by default — it ignores fields unless IncludeFields = true, then writes Item1, Item2).
• dynamic, data binding, logging templates and ToString() ((42, 99.5)) don't know the names.
• Names don't affect type identity: (int A, int B) and (int X, int Y) are the same type and assignable (with a warning if names mismatch in some contexts).

3. Tuple equality

Since C# 7.3, == and != compare element-wise (with each element's own ==), and Equals uses EqualityComparer<T>.Default per element:

(1, "a") == (1, "a");   // true

Tuples implement IEquatable<ValueTuple<...>>, IComparable, IStructuralEquatable, making them usable as dictionary keys and in GroupBy/Distinct — e.g. Dictionary<(string Region, int Year), decimal>.

4. Mutability

ValueTuple fields are mutable: s.Total = 0; compiles. Because it's a struct, you mutate your copy, which is usually fine for locals but surprising when tuples are stored in collections or properties (modifying a copy). Treat tuples as immutable values by convention.

5. Performance

• No heap allocation for the tuple itself (struct) — good for hot paths returning multiple values instead of out parameters or small classes.
• Large tuples (many elements, or tuples of large structs) are copied by value on every assignment and return.
• Tuples with more than 7 elements nest a TRest tuple (ValueTuple<T1..T7, ValueTuple<T8...>>) — a sign you need a named type.
• Equality/hashing is element-wise and efficient.

6. Serialisation pitfalls

• System.Text.Json ignores fields by default → a tuple serialises as {}; with IncludeFields, as {"Item1":42,"Item2":99.5} — element names are lost.
• APIs returning tuples produce useless or wrong JSON and OpenAPI schemas.
• Changing tuple element order or types in public APIs is a breaking change that names don't protect against.
• Logging a tuple with structured logging captures it as (42, 99.5).

7. When to use a record instead

Use a record when the data:

• crosses a public API or assembly boundary,
• is serialised (HTTP, messages, cache),
• lives in a field/property or collection for long,
• has more than ~3 elements,
• needs behaviour, validation or documentation.

public readonly record struct Summary(int Count, decimal Total); gives names that survive at run time, immutability and value equality with similar performance to a tuple.

8. A production example

A minimal API endpoint returned (int Count, decimal Total) and the mobile app received {} — System.Text.Json ignored the fields. A developer "fixed" it with IncludeFields = true globally, and the app then received Item1/Item2, which the app team hard-coded. When the tuple's order was later swapped in a refactor, totals and counts were silently reversed in the app. We replaced it with a record SummaryResponse(int Count, decimal Total) and removed IncludeFields.