How do structs work in C#? Explain value semantics and copying, constructors and default values, readonly structs and readonly members, ref structs and Span, record structs, boxing, and the bugs that mutable structs cause.

How I would answer this in an interview

A struct is a value type: a variable contains the data itself, and assignment, argument passing and returning copy it. Structs are for small, immutable values where avoiding heap allocation matters. I'd cover copying, constructors and defaults, readonly structs and members, ref struct and Span<T>, record structs, boxing, and the bugs mutable structs cause.

1. Value semantics and copying

public struct Point { public int X; public int Y; }

var a = new Point { X = 1, Y = 2 };
var b = a;      // full copy
b.X = 99;       // a.X still 1

• Structs live inline wherever their variable lives: on the stack for locals, inside the object for fields of a class, contiguously inside arrays.
• Copy cost equals the struct's size; small structs (≤ 16 bytes) are cheap — often passed in registers; large structs cost a memcpy on every assignment/call.
• No heap allocation and no GC tracking for the struct itself — the main benefit.

2. Constructors and default values

• Every struct has a default value with all fields zeroed (default(Point)), and the runtime creates it without running any constructor — for array elements, uninitialised fields and default.
• C# 10 allows explicit parameterless constructors and field initialisers, but they only run for new Point(), not for default or array elements.
• C# 11 auto-defaults fields not assigned in a constructor (previously CS0171).
• Design rule: the all-zero value must be valid or detectable (IsDefault), e.g. Money with Currency == null.

3. readonly structs and members

public readonly struct Money(decimal amount, string currency)
{
    public decimal Amount { get; } = amount;
    public string Currency { get; } = currency;
    public Money Add(Money other) => new(Amount + other.Amount, Currency);   // returns a new value
}

• readonly struct makes all fields readonly, guarantees immutability, and lets the compiler avoid defensive copies when the struct is accessed via in parameters, readonly fields or ref readonly returns.
• readonly members (public readonly double Length() => ...) mark individual methods as non-mutating in a mutable struct.

4. ref struct and Span<T>

ref struct types (e.g. Span<T>, ReadOnlySpan<T>, Utf8JsonReader) must stay on the stack:

• Can't be boxed, stored in fields of classes or regular structs, captured by lambdas, or (before C# 13) used in async methods/iterators.
• They can contain ref fields (C# 11), which is how Span<T> holds a managed pointer to arrays, strings, stack memory or native memory.
• C# 13 lets ref structs implement interfaces and be used as generic arguments with allows ref struct, still without boxing.

This enables zero-allocation, memory-safe slicing of buffers.

5. Record structs

readonly record struct OrderId(Guid Value) generates fast value equality (IEquatable<T>, GetHashCode), ==, ToString, deconstruction and with. Ideal for strongly typed IDs and small value objects; much better than ValueType's default reflection-based Equals.

6. Boxing

Converting a struct to object, ValueType, or an interface allocates a box on the heap and copies the value. Hidden boxing appears with non-generic collections, object parameters (string.Format), interface parameters, Equals(object) on structs without IEquatable<T>, and calling non-overridden ToString/GetHashCode. Generics with constraints avoid boxing.

7. Bugs mutable structs cause

var points = new List<Point> { new() { X = 1 } };
points[0].X = 5;                 // CS1612: can't modify the return value (it's a copy)
foreach (var p in points) p.X = 5;   // CS1654 / or silently modifies a copy in other patterns

readonly Point _origin;
_origin.Move(1, 1);              // mutating method runs on a defensive copy - no effect!

IMovable m = point; m.Move(1, 1);   // boxes - mutates the box, not 'point'

Lost updates are silent and confusing. Microsoft's guidance: structs should be immutable ("mutable structs are evil" — Eric Lippert). Make them readonly and return new values.

8. A production example

A telemetry ingestion pipeline modelled readings as a 24-byte readonly record struct Reading(DateTime At, float Value, int SensorId) stored in arrays and spans; switching from a class saved millions of allocations per minute and roughly halved GC time. In the same codebase, a mutable struct Counter stored in a Dictionary<string, Counter> never incremented because dict[key].Increment() modified a copy — we changed it to CollectionsMarshal.GetValueRefOrAddDefault to mutate in place, and later to an immutable struct with replace-on-update.