3.8 · deinit rules, process exit, isolated deinit, noncopyable types and consume

The first pass explained when an object dies. This one covers what deinit may and may not do, which objects never get one, and how Swift 6 lets you state ownership in types.

Mental model. deinit is a last call, not a destructor you can rely on for everything: the object is already dying (weak references read nil), it cannot be kept alive, and some objects never get the call at all.

What deinit can and cannot do

Dying objects, escaped self, process exit and actor isolation.

1. What state is an object in while its deinit runs, and what happens if you let self escape from it? 3.8.1 · L3
   By the time deinit starts the strong count has already hit zero and the object is committed to dying. Weak references to it already read nil, even from inside…
2. Does deinit run when the app exits, and which objects never get one? 3.8.2 · L3
   No. At process exit nothing is torn down: Swift does not release globals or static properties, so objects reachable from a top-level let or a static let shared…
3. Which thread does deinit run on, and what does isolated deinit change for actors and main-actor classes? 3.8.3 · L5
   A plain deinit runs on the thread that released the last reference, whatever the class’s isolation. In the check a @MainActor class whose last reference is…

Ownership you can state

Noncopyable types and the consume operator.

1. How do noncopyable types behave in practice: deinit on a struct, consuming and borrowing methods, discard, and what they cannot do yet? 3.8.4 · L5
   A ~Copyable struct or enum has unique ownership enforced by the compiler: assigning or passing it moves it, and using it afterwards is an error. That makes it…
2. What does the consume operator do for ordinary values, and does it release a class instance earlier? 3.8.5 · L5
   let y = consume x ends the variable x: using it again is a compile error (“'x' used after consume”). It tells the compiler to move the value instead of copying…

More in Memory, ARC & runtime

• 3.1 · ARC, autorelease pools, object lifetime
• 3.2 · strong, weak, unowned, unowned(unsafe)
• 3.3 · Cycles: delegates, closures, timers, Combine, tasks
• 3.4 · Object layout, side tables, tagged pointers
• 3.5 · The copy-on-write mechanism
• 3.6 · Retain traffic, parameter conventions, Unmanaged, bridging
• 3.7 · Leaks, abandoned memory, footprint, and the tools
• 3.9 · Weak collections, nested closures, structs holding references, weak let and escaped pointers
• 3.10 · Enum layout, existential boxing, tail allocation, slice retention, growth and the command-line tools