When is teaching “always use structs” harmful on a team?
Mental model. “Always use structs” is a compass that points north everywhere — including when you are going south.
When it produces giant mutable structs copied across threads, or when UIKit/NSManagedObject gets wrapped in cargo-cult structs that still share references inside. The slogan hides the real question: who owns this, and what is shared?
It also encourages retrofitting value types onto things with real identity — a socket, a player, a session — where copying semantics are actively wrong.
The staff+ bar: code review looks for identity leaks and unclear ownership, not for whether the keyword says struct.
Common traps
- Treating the keyword as the design. A struct containing a class is a reference type with extra steps.
- Assuming value types are automatically thread-safe. A struct with a shared reference inside is just as racy.
They might follow up with
- What should the team guideline say instead? “Model ownership explicitly; document what is shared; prefer values when copies should be independent.”
- How do you catch violations? Review the boundaries: the initializer, the escape points, and anything crossing an isolation domain.
Related questions
- 1.1.1 What is the difference between a value type and a reference type in Swift? When do you choose each?
- 1.1.4 When would you still use a class in a Swift-first codebase?
- 1.1.5 How do you design a public Swift type: struct vs class vs actor vs enum?
- 1.5.6 unowned var view = UIView() then print(view) — what happens?
← How do you design a public Swift type: struct vs class vs actor vs… What is copy-on-write? Which types use it? →