When should you use a struct instead of a class?
Quick Answer
Use a struct only when the type is small (roughly ≤ 16–24 bytes), logically a single value, immutable, and frequently created — a point, a money amount, an RGBA colour. Everything else is a class. Large or mutable structs are a trap: they're copied on every assignment and argument pass, which is slower, and mutable-value semantics surprise people.
My default is a class. I only reach for a struct when the type is small, represents a single value, and is immutable — a point, a currency amount, a date range. In those cases you avoid a heap allocation and GC pressure. But a big struct or a mutable struct is worse than a class: it gets copied every time you pass it around, and mutable value semantics confuse everyone. If I do use one I make it a readonly struct so the compiler enforces immutability and doesn't make defensive copies.
- Pros of a struct: no heap allocation (lives inline / on the stack), no GC pressure, value equality intent.
- Cons: copy cost grows with size; boxing when cast to an interface or
object; can't benull(useT?); default value is all-zero (no way to require a constructor before C# 11). - Prefer
readonly struct(compiler enforces immutability, avoids defensive copies) andrecord structfor value equality boilerplate. ref struct(likeSpan<T>) can't be boxed or captured — for stack-only performance types.