Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Xinyu (Sean) Zhang
Courses Plus Student 7,064 PointsDifference between [weak self] and [unowned self]
Before the closure execution, what is the retain count for self?
Since the variable value was referenced inside the closure but was declared outside of the closure, does the self 's retain count increased by 1?
- Case with [weak self] : When the closure execution starts but before the self.value called, what is the retain count for the self? What is the retain count for the self after the closure call?
- Case with [unowned self] : When the closure execution starts but before the self.value called, what is the retain count for the self? What is the retain count for the self after the closure call?
1 Answer
Xavier D
Courses Plus Student 5,840 PointsHi,
I retrieved the following below at: weak unowned link. From what I gathered, unowned self can't be nil but weak self can be, and unowned self can lead to dangling pointers...something infamous in Objective-C. Hope it helps
"UNOWNED Weak and unowned references behave similarly but are NOT the same. Unowned references, like weak references, do not increase the retain count of the object being referred. However, in Swift, an unowned reference has the added benefit of not being an Optional. This makes them easier to manage rather than resorting to using optional binding. This is not unlike Implicitly Unwrapped Optionals . In addition, unowned references are non-zeroing. This means that when the object is deallocated, it does not zero out the pointer. This means that use of unowned references can, in some cases, lead to dangling pointers. For you nerds out there that remember the Objective-C days like I do, unowned references map to unsafe_unretained references.
This is where it gets a little confusing. Weak and unowned references both do not increase retain counts. They can both be used to break retain cycles. So when do we use them?! According to Apple's docs: “Use a weak reference whenever it is valid for that reference to become nil at some point during its lifetime. Conversely, use an unowned reference when you know that the reference will never be nil once it has been set during initialization.” Well there you have it: Just like an implicitly unwrapped optional, If you can guarantee that the reference will not be nil at its point of use, use unowned. If not, then you should be using weak.