guard let self = self else { return } inside a closure — what does it do to ARC?

1.5.2 · L3 · Interview

Mental model. You have a visitor badge (weak). The guard upgrades it to a full access pass for the rest of the visit.

It promotes the weak reference to a strong local for the remainder of the scope. That means self cannot deallocate while the body runs — usually exactly what you want.

It is not a leak by itself. A leak requires a cycle: an object that strongly retains the closure while the closure strongly retains the object (a stored work item, a Combine sink, a repeating timer).

Common traps

  • “guard let self creates a retain cycle.” No. It creates a temporary strong reference for the duration of the closure body.
  • Weak-capturing everything by reflex. If the work must happen, a weak self may silently skip it. Decide per closure, not per project.

They might follow up with

  • What changed in Swift 5.8? Implicit self in escaping closures became allowed after an explicit guard let self, so you no longer need self. everywhere.
  • How do you avoid the cycle entirely? Do not store the closure on the object it captures, or break the stored reference on completion/cancel.

Related questions

  • 1.5.1 Escaping vs non-escaping closures?
  • 1.5.4 What does a capture list like [weak self], [unowned self], [self], or [foo] actually do?

← Escaping vs non-escaping closures?   Why are closures called reference types? What is a closure context? →