Memory implications of captures in Swift - Step-by-Step Execution

Concept Flow - Memory implications of captures

Define closure with capture

↓

Closure captures variables

↓

Variables retained in closure's memory

↓

Closure used or stored

↓

Memory retained until closure released

↓

Closure released -> memory freed

This flow shows how a closure captures variables, retains them in memory, and how memory is freed when the closure is released.

Execution Sample

Swift

var x = 10
let closure = { print(x) }
x = 20
closure()

This code defines a closure capturing variable x, changes x, then calls the closure to print x.

Execution Table

Step	Action	Variable x	Closure captures	Output
1	Initialize x	10	None yet
2	Define closure capturing x	10	Captures x by reference
3	Change x to 20	20	Closure still captures x by reference
4	Call closure	20	Closure uses current x value	20
5	Closure released (end of scope)	20	Memory freed

💡 Closure released, memory for captured variables freed

Variable Tracker

Variable	Start	After 1	After 2	After 3	Final
x	10	10	10	20	20
closure capture	None	None	x by reference	x by reference	Released

Key Moments - 3 Insights

Does the closure capture the value of x at definition or the current value when called?

The closure captures x by reference, so it uses the current value when called, as shown in step 4 of the execution_table.

When is the memory for captured variables freed?

Memory is freed when the closure is released or goes out of scope, as shown in step 5 of the execution_table.

What happens if the closure captures a variable strongly and the closure is stored in that variable?

This creates a retain cycle causing memory to not be freed, but this example uses a simple capture without retain cycles.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of x when the closure is called at step 4?

A 10

B 20

C Closure does not access x

D Undefined

💡 Hint

See 'Variable x' column at step 4 in execution_table

At which step does the closure capture variable x?

A Step 2

B Step 3

C Step 1

D Step 4

💡 Hint

Check 'Closure captures' column in execution_table

If x was captured by value instead of reference, what would the output be at step 4?

A Closure would not compile

B 20

C 10

D 0

💡 Hint

Captured value means closure uses x's value at definition (step 2)

Concept Snapshot

Swift closures capture variables by reference by default.
Captured variables are retained in memory as long as the closure exists.
Changing a captured variable affects closure output if captured by reference.
Memory is freed when closure is released.
Avoid retain cycles to prevent memory leaks.

Full Transcript

This visual trace shows how Swift closures capture variables and the memory implications. Initially, variable x is set to 10. When the closure is defined, it captures x by reference, not by value. Changing x to 20 before calling the closure means the closure prints 20, the current value. The closure holds a reference to x, retaining it in memory. When the closure is released, the memory for captured variables is freed. This example helps understand that closures capture variables by reference, affecting memory and behavior.

Practice

1. What happens when a Swift closure captures a variable strongly by default?

easy

A. The closure keeps a strong reference, potentially causing memory leaks if not handled.

B. The variable is copied and changes inside the closure do not affect the original.

C. The closure does not keep any reference to the variable.

D. The variable is automatically released when the closure is created.

Solution

1. Step 1: Understand default capture behavior

   By default, Swift closures capture variables strongly, meaning they keep a reference to the original variable.

2. Step 2: Recognize memory implications

   If the closure and the captured variable reference each other, it can cause a retain cycle, leading to memory leaks.

3. Final Answer:

   The closure keeps a strong reference, potentially causing memory leaks if not handled. -> Option A

4. Quick Check:

   Strong capture = possible memory leak [OK]

Hint: Strong capture keeps variables alive, watch for retain cycles [OK]

Common Mistakes:

• Thinking variables are copied by default
• Assuming closures do not hold references
• Believing variables auto-release on capture

2. Which syntax correctly declares a capture list to weakly capture a variable self in a Swift closure?

easy

A. { (weak self) in print(self) }

B. { self weak in print(self) }

C. { weak self -> Void in print(self) }

D. { [weak self] in print(self) }

Solution

1. Step 1: Recall capture list syntax

   Capture lists are declared inside square brackets before the closure parameters, e.g., [weak self].

2. Step 2: Match correct syntax

   { [weak self] in print(self) } uses the correct syntax: { [weak self] in ... }.

3. Final Answer:

   { [weak self] in print(self) } -> Option D

4. Quick Check:

   Capture list uses square brackets [weak self] [OK]

Hint: Capture lists use square brackets before closure parameters [OK]

Common Mistakes:

• Using parentheses instead of square brackets
• Placing 'weak' outside capture list
• Incorrect arrow syntax in capture list

3. What will be printed by the following Swift code?

class Person {
    var name = "Alice"
    lazy var greet: () -> Void = { [unowned self] in
        print("Hello, \(self.name)!")
    }
}
let p = Person()
p.greet()

medium

A. Hello, !

B. Hello, Optional("Alice")!

C. Hello, Alice!

D. Runtime error due to unowned reference

Solution

1. Step 1: Analyze closure capture

   The closure captures self as unowned, meaning it expects self to always exist when called.

2. Step 2: Check code execution

   Instance p is created, greet closure is called, printing "Hello, Alice!" using self.name.

3. Final Answer:

   Hello, Alice! -> Option C

4. Quick Check:

   Unowned capture prints value safely if object exists [OK]

Hint: Unowned captures assume object exists, no optional needed [OK]

Common Mistakes:

• Expecting Optional wrapping in output
• Thinking unowned causes runtime error immediately
• Assuming empty string prints

4. Identify the problem in this Swift code snippet and how to fix it:

class ViewController {
    var title = "Main"
    lazy var printTitle = {
        print(self.title)
    }
}
let vc = ViewController()
vc.printTitle()

medium

A. No problem, code runs fine and prints "Main".

B. Retain cycle due to strong self capture; fix with [weak self] capture list.

C. Syntax error: missing capture list brackets.

D. Runtime error: self is nil inside closure.

Solution

1. Step 1: Identify capture type

   The closure captures self strongly by default, which can cause retain cycles if ViewController holds the closure.

2. Step 2: Fix with weak capture

   Adding [weak self] in the capture list prevents retain cycle by capturing self weakly.

3. Final Answer:

   Retain cycle due to strong self capture; fix with [weak self] capture list. -> Option B

4. Quick Check:

   Strong capture in closures can cause retain cycles [OK]

Hint: Use [weak self] to avoid retain cycles in closures [OK]

Common Mistakes:

• Ignoring retain cycles in lazy properties
• Assuming no capture means no memory issues
• Confusing syntax errors with memory issues

5. You have a Swift class with a closure property that captures a variable data. You want to ensure the closure does not keep data alive if the class instance is deallocated, but still access data safely inside the closure. Which capture strategy should you use?

hard

A. Capture data weakly and unwrap it safely inside the closure.

B. Capture data unowned without checks inside the closure.

C. Capture data strongly to keep it alive as long as the closure exists.

D. Do not capture data at all; pass it as a parameter instead.

Solution

1. Step 1: Understand capture effects on memory

   Strong capture keeps data alive, which may cause memory leaks if the class is deallocated.

2. Step 2: Choose safe capture method

   Weak capture allows data to be nil if deallocated; unwrapping safely avoids crashes.

3. Step 3: Compare with unowned and no capture

   Unowned assumes data always exists, risking crashes. Not capturing requires passing data every time, which may be inconvenient.

4. Final Answer:

   Capture data weakly and unwrap it safely inside the closure. -> Option A

5. Quick Check:

   Weak capture + safe unwrap = safe memory handling [OK]

Hint: Use weak capture and optional unwrap for safe memory use [OK]

Common Mistakes:

• Using unowned and risking runtime crashes
• Strong capture causing retain cycles
• Ignoring safe unwrapping of weak references