I´m trying to integrate Face/Touch ID Login and I saw [unowned self] in Apple's documentation, inside a closure. What is that and what are the benefits?
Example code:
let context = LAContext()
var error: NSError?
if context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) {
let reason = "Identify yourself!"
context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: reason) {
[unowned self] (success, authenticationError) in
DispatchQueue.main.async {
if success {
print("Authenticated!")
} else {
// error
}
}
}
} else {
// no biometry
}
Long story short, it's the same as weak!, since unowned references are just weak references that are guaranteed to have a value.
unowned is used when you're sure that the reference will NEVER be nil, and therefore, it can only be evaluated with non nil values.
Like weak references, an unowned reference does not keep a strong hold on the instance it refers to. Unlike a weak reference, however, an unowned reference is assumed to always have a value. Because of this, an unowned reference is always defined as a non-optional type. (Apple Docs)
Check this other answer:
What is the difference between a weak reference and an unowned reference?
Docs: ARC Documentation
The unowned qualifier, like weak, prevents the closure from establishing a strong reference to to self which can be helpful in preventing strong reference cycles. The benefit of unowned over weak is that it’s a tad more efficient in optimized builds, not requiring it to keep track of this reference and go back and set it to nil when the object to which it references is deallocated. The unowned reference also is not an optional, meaning that you don’t have to unwrap it, eliminating syntactic noise and simplifying one’s code.
But you obviously can’t use unowned in any situation where the object might be deallocated, because it obviously can no longer keep a reference to the memory for a deallocated object.
Interestingly, the evaluatePolicy(_:localizedReason:reply:) documentation says, “This method asynchronously evaluates an authentication policy.” Any time you’re dealing with an asynchronous method, it is not advisable to use unowned, because you cannot be assured that the object in question hasn’t been deallocated in the intervening time. Only use unowned in those specific situations where you know, for a fact, that the closure cannot be called if the object has been deallocated. That would not appear to be the case here.
Bottom line, use unowned to avoid strong reference cycles and where you want cleaner, slightly more efficient code. But only do so when you know that it is impossible for the object to be deallocated before closure is called.
Related
I see a lot of code like this:
DispatchQueue.main.async {
self.tableView.reloadData()
}
In this context, where tableView is a property of self, should one instead ensure weak self is captured like this:
DispatchQueue.main.async { [weak self] in
self?.tableView.reloadData()
}
I think so, but this type of "unsafe" code is so ubiquitous across codebases I wonder if I'm missing something?
You said:
In this context, where tableView is a property of self, should one instead ensure weak self is captured like this:
DispatchQueue.main.async { [weak self] in
self?.tableView.reloadData()
}
No, you don’t actually need to use weak reference to self in this case. There is no persistent strong reference cycle here. The worst that would happen (in the absence of weak reference) is that it will keep a strong reference to self until the dispatched block finishes running. But that closure will generally run practically immediately and the fleeting strong reference will be eliminated very quickly.
So, as such, no, you don’t have to use weak reference here. It is not technically incorrect to do so, but adds a syntactic noise for practically no benefit. Yes, we should be diligent about breaking potential strong reference cycles with weak references, but this is not one of those cases.
By the way, the choice of the term “unsafe” muddles the topic a bit. “Unsafe” has a very specific meaning when talking about memory references: It generally refers to dangling references to deallocated objects when not using runtime safety checks. As The Swift Programming Language: Automatic Reference Counting says (emphasis from original):
Swift also provides unsafe unowned references for cases where you need to disable runtime safety checks—for example, for performance reasons. As with all unsafe operations, you take on the responsibility for checking that code for safety.
You indicate an unsafe unowned reference by writing unowned(unsafe). If you try to access an unsafe unowned reference after the instance that it refers to is deallocated, your program will try to access the memory location where the instance used to be, which is an unsafe operation.
Obviously, both strong and weak references are safe (the former keeps the object from being released, the latter sets its references to nil when the object is deallocated). Even unowned references often employ runtime safety checks (though it still results in runtime error if you use a unowned reference after the object is deallocated). An “unsafe” reference is used in high-performance scenarios, where you are absolutely confident in your unowned references are being handled properly and that you’re willing to run your code without runtime safety checks.
I suspect you didn’t mean “unsafe” in this context, but I mention it so that you are aware of the very specific meaning that this word has within the context of ARC and memory management.
Lets examine the following example
SomeLib.someAsyncFunction { [weak someVariable] in
if let someVariableU = someVariable {
// now someVariableU is unwrapped and strong reference created , we can use it as regular
}
}
I assume that optional binding has a low level implementation similar(not exactly of course) to something like this
if variable != nil {
return variable!
}
So, my question - is it possible that the object referenced by weak reference will deallocated during optional binding, I mean the last strong reference to the object is "cleared". If so what will happen in this case?
What will happen if the "nil check will pass" and then it will be deallocated, what will happen to "force unwrap"(I used parentheses because I understand that it's not exactly how it works)!
So, can somebody explain if this situation is even possible, and is o than what will happen?
This entire structure, which dates back way into the Objective-C days, is traditionally called the "weak–strong dance". Let me explain the purpose of the dance.
Our overall purpose is: avoid the danger of a retain cycle and memory leak. That is why we say weak somevariable.
Having done that, however, we do indeed introduce the danger that the object pointed to by somevariable might be deallocated. However, we deal coherently with that danger, by saying if let. Here's how:
The object might have been deallocated by the time we enter the first curly braces in your code. But that's not a problem. The if let means that if the object has been deallocated, then in that case we get nil and we do nothing (we never enter the second curly braces).
If the object has not been deallocated by the first curly braces, then the if let succeeds, and then, as Cristik says, the if let creates a strong reference and now we enter the second curly braces with a guarantee that the object will persist for their entirety.
Thus, we get coherent and consistent behavior.
SomeLib.someAsyncFunction { // someVariable might be deallocated...
[weak someVariable] in // ...and that is the point of `weak`, to allow that
if let someVariableU = someVariable { // find out whether someVariable was deallocated
// if we get here, someVariable was _not_ deallocated...
// and someVariableU is a strong reference and persists thru this block
}
}
No, the object won't be deallocated during the execution of the optional binding block.
if let someVariableU = someVariable creates a strong reference, thus as long as that strong reference will be alive, so will the object it points to.
After reading some articles and developer guide of apple, i'm still confused about Capture List in closure.
What does it mean "capture", how does it work behind the scene in terms of unowned self and weak self? how the closure use self without owning the object?
I thought it like making a copy of that object so when it get finished it's passed from the stack like value type, but i guess that i'm wrong.
I'm hoping that someone here can make it more easier and clear for understanding, or linked me to a good article that answering this specific question.
Thanks for advance
My understanding, and it might be a bit simplified, is that it is about ownership and holding on to an object, meaning that as long as we claim ownership of an object it can not be freed from memory even another part of the code sets it to nil or similar.
With weakwe say that it is okay to destroy the object and that we will only use it if it is still around.
So when declaring self as weak in a closure we say that if self is still around when it's time to execute the closure we do so normally otherwise the closure will silently be ignored without generating an error.
It's mainly to do with reference counting. Any instance that is used inside a closure (but was declared outside) is strongly referenced (i.e. its reference count is incremented). This can lead to retain cycles, e.g.
class MyClass {
var myClosure: (() -> Void)!
init() {
myClosure = {
self.foo()
}
}
func foo() {
}
}
In the above example the instance of MyClass retains a reference to myClosure and vice versa, meaning that the MyClass instance will stay in memory forever.
You can also have more complex/harder-to-spot retain cycles, so you need to really pay attention and if you ever have any doubts add some print calls to your class' deinit methods just to make sure (or use Instruments).
In order to avoid these issues you can mark objects being captured in closures as unowned or weak. This means that their reference count won't be increased and you can avoid these retain cycles. The above example could have either been done this way:
myClosure = { [weak self] in
self?.foo()
}
or, better yet for this example, this way:
myClosure = { [unowned self] in
self.foo()
}
While the first way is always safe and what you will more likely do, the unowned version is easy to reason in this example because you know that myClosure won't outlive self. However, if you're not 100% sure that self will always outlive the closure use weak.
Also note that you can mark how to capture multiple objects used inside the closure, just separate it by commas, e.g.
myClosure = { [weak self, unowned bar] in
self?.foo(bar)
}
If we keep in mind that captured values are strong references in closures by default, we can assume that this can create retain cycles (bad stuff).
A capture list is an array of variables you can pass into a closure. The purpose of capture lists is to change the strenght of the variables that are passed in. This is used to break retain cycles.
For instance:
// strong reference
[label = self.myLabel!] in
// weak reference
[weak label = self.myLabel!] in
// unowned reference
[unowned self] in
In WWDC 2014 session 403 Intermediate Swift and transcript, there was the following slide
The speaker said in that case, if we don't use [unowned self] there, it will be a memory leak. Does it mean we should always use [unowned self] inside closure?
On line 64 of ViewController.swift of the Swift Weather app, I don't use [unowned self]. But I update the UI by using some #IBOutlets like self.temperature and self.loadingIndicator. It may be OK because all #IBOutlets I defined are weak. But for safety, should we always use [unowned self]?
class TempNotifier {
var onChange: (Int) -> Void = {_ in }
var currentTemp = 72
init() {
onChange = { [unowned self] temp in
self.currentTemp = temp
}
}
}
No, there are definitely times where you would not want to use [unowned self]. Sometimes you want the closure to capture self in order to make sure that it is still around by the time the closure is called.
Example: Making an asynchronous network request
If you are making an asynchronous network request you do want the closure to retain self for when the request finishes. That object may have otherwise been deallocated but you still want to be able to handle the request finishing.
When to use unowned self or weak self
The only time where you really want to use [unowned self] or [weak self] is when you would create a strong reference cycle. A strong reference cycle is when there is a loop of ownership where objects end up owning each other (maybe through a third party) and therefore they will never be deallocated because they are both ensuring that each other stick around.
In the specific case of a closure, you just need to realize that any variable that is referenced inside of it, gets "owned" by the closure. As long as the closure is around, those objects are guaranteed to be around. The only way to stop that ownership, is to do the [unowned self] or [weak self]. So if a class owns a closure, and that closure captures a strong reference to that class, then you have a strong reference cycle between the closure and the class. This also includes if the class owns something that owns the closure.
Specifically in the example from the video
In the example on the slide, TempNotifier owns the closure through the onChange member variable. If they did not declare self as unowned, the closure would also own self creating a strong reference cycle.
Difference between unowned and weak
The difference between unowned and weak is that weak is declared as an Optional while unowned is not. By declaring it weak you get to handle the case that it might be nil inside the closure at some point. If you try to access an unowned variable that happens to be nil, it will crash the whole program. So only use unowned when you are positive that variable will always be around while the closure is around
Update 11/2016
I wrote an article on this extending this answer (looking into SIL to understand what ARC does), check it out here.
Original answer
The previous answers don't really give straightforward rules on when to use one over the other and why, so let me add a few things.
The unowned or weak discussion boils down to a question of lifetime of the variable and the closure that references it.
Scenarios
You can have two possible scenarios:
The closure have the same lifetime of the variable, so the closure will be reachable only until the variable is reachable. The variable and the closure have the same lifetime. In this case you should declare the reference as unowned. A common example is the [unowned self] used in many example of small closures that do something in the context of their parent and that not being referenced anywhere else do not outlive their parents.
The closure lifetime is independent from the one of the variable, the closure could still be referenced when the variable is not reachable anymore. In this case you should declare the reference as weak and verify it's not nil before using it (don't force unwrap). A common example of this is the [weak delegate] you can see in some examples of closure referencing a completely unrelated (lifetime-wise) delegate object.
Actual Usage
So, which will/should you actually use most of the times?
Quoting Joe Groff from twitter:
Unowned is faster and allows for immutability and nonoptionality.
If you don't need weak, don't use it.
You'll find more about unowned* inner workings here.
* Usually also referred to as unowned(safe) to indicate that runtime checks (that lead to a crash for invalid references) are performed before accessing the unowned reference.
I thought I would add some concrete examples specifically for a view controller. Many of the explanations, not just here on Stack Overflow, are really good, but I work better with real world examples (#drewag had a good start on this):
If you have a closure to handle a response from a network requests use weak, because they are long lived. The view controller could close before
the request completes so self no longer points to a valid object when the closure is called.
If you have closure that handles an event on a button. This can be unowned because as soon as the view controller goes away, the button and any other items it may be referencing from self goes away at the same time. The closure block will also go away at the same time.
class MyViewController: UIViewController {
#IBOutlet weak var myButton: UIButton!
let networkManager = NetworkManager()
let buttonPressClosure: () -> Void // closure must be held in this class.
override func viewDidLoad() {
// use unowned here
buttonPressClosure = { [unowned self] in
self.changeDisplayViewMode() // won't happen after vc closes.
}
// use weak here
networkManager.fetch(query: query) { [weak self] (results, error) in
self?.updateUI() // could be called any time after vc closes
}
}
#IBAction func buttonPress(self: Any) {
buttonPressClosure()
}
// rest of class below.
}
If self could be nil in the closure use [weak self].
If self will never be nil in the closure use [unowned self].
The Apple Swift documentation has a great section with images explaining the difference between using strong, weak, and unowned in closures:
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html
Here is brilliant quotes from Apple Developer Forums described delicious details:
unowned vs unowned(safe) vs unowned(unsafe)
unowned(safe) is a non-owning reference that asserts on access that
the object is still alive. It's sort of like a weak optional reference
that's implicitly unwrapped with x! every time it's accessed.
unowned(unsafe) is like __unsafe_unretained in ARC—it's a non-owning
reference, but there's no runtime check that the object is still alive
on access, so dangling references will reach into garbage memory.
unowned is always a synonym for unowned(safe) currently, but the
intent is that it will be optimized to unowned(unsafe) in -Ofast
builds when runtime checks are disabled.
unowned vs weak
unowned actually uses a much simpler implementation than weak.
Native Swift objects carry two reference counts, and unowned
references bump the unowned reference count instead of the strong
reference count. The object is deinitialized when its strong reference
count reaches zero, but it isn't actually deallocated until the
unowned reference count also hits zero. This causes the memory to be
held onto slightly longer when there are unowned references, but that
isn't usually a problem when unowned is used because the related
objects should have near-equal lifetimes anyway, and it's much simpler
and lower-overhead than the side-table based implementation used for
zeroing weak references.
Update: In modern Swift weak internally uses the same mechanism as unowned does. So this comparison is incorrect because it compares Objective-C weak with Swift unonwed.
Reasons
What is the purpose of keeping the memory alive after owning references reach 0? What happens if code attempts to do something with
the object using an unowned reference after it is deinitialized?
The
memory is kept alive so that its retain counts are still available.
This way, when someone attempts to retain a strong reference to the
unowned object, the runtime can check that the strong reference count
is greater than zero in order to ensure that it is safe to retain the
object.
What happens to owning or unowned references held by the object? Is their lifetime decoupled from the object when it is deinitialized or
is their memory also retained until the object is deallocated after
the last unowned reference is released?
All resources owned by the object are released as soon as the object's
last strong reference is released, and its deinit is run. Unowned
references only keep the memory alive—aside from the header with the
reference counts, its contents is junk.
Excited, huh?
There are some great answers here. But recent changes to how Swift implements weak references should change everyone's weak self vs. unowned self usage decisions. Previously, if you needed the best performance using unowned self was superior to weak self, as long as you could be certain that self would never be nil, because accessing unowned self is much faster than accessing weak self.
But Mike Ash has documented how Swift has updated the implementation of weak vars to use side-tables and how this substantially improves weak self performance.
https://mikeash.com/pyblog/friday-qa-2017-09-22-swift-4-weak-references.html
Now that there isn't a significant performance penalty to weak self, I believe we should default to using it going forward. The benefit of weak self is that it's an optional, which makes it far easier to write more correct code, it's basically the reason Swift is such a great language. You may think you know which situations are safe for the use of unowned self, but my experience reviewing lots of other developers code is, most don't. I've fixed lots of crashes where unowned self was deallocated, usually in situations where a background thread completes after a controller is deallocated.
Bugs and crashes are the most time-consuming, painful and expensive parts of programming. Do your best to write correct code and avoid them. I recommend making it a rule to never force unwrap optionals and never use unowned self instead of weak self. You won't lose anything missing the times force unwrapping and unowned self actually are safe. But you'll gain a lot from eliminating hard to find and debug crashes and bugs.
According to Apple-doc
Weak references are always of an optional type, and automatically
become nil when the instance they reference is deallocated.
If the captured reference will never become nil, it should always be captured as an unowned reference, rather than a weak reference
Example -
// if my response can nil use [weak self]
resource.request().onComplete { [weak self] response in
guard let strongSelf = self else {
return
}
let model = strongSelf.updateModel(response)
strongSelf.updateUI(model)
}
// Only use [unowned self] unowned if guarantees that response never nil
resource.request().onComplete { [unowned self] response in
let model = self.updateModel(response)
self.updateUI(model)
}
unowned is similar to weak they don't a retained object from being destroyed, but weak variables turned to nil when the object its a reference to no longer exists, which we can handle with the normal checking of nils, unowned will just become garbage, you can't tell they are no longer garbage and using them will crash. The problem with weak is if an object has references to it by weak variables, when its destroyed, it has to go through every reference to it and set that variable to nil, this clearly is going to be expensive, using unowned instead is going just crash and finding this kind of bug is going to be difficult. One place to use unowned is if you are creating some carefully contained datatype, which has a clear interface, and its internals are not directly accessible, for you implementation it may be useful to have lots of circular references but that are self contained, you can used unowned references to let you break those circular references, with out the expense of weak variables, for example you may have a node tree, and each node needs has to have a reference to its parent, deleting a node is going to delete all its children, so there is no point of all the children having to have all there parent references set to nil.
If none of the above makes sense:
tl;dr
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.
Explanation:
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 initialisation.”
import UIKit
class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
let storyboard = UIStoryboard(name: "Main", bundle: nil)
let controller = storyboard.instantiateViewController(withIdentifier: "AnotherViewController")
self.navigationController?.pushViewController(controller, animated: true)
}
}
import UIKit
class AnotherViewController: UIViewController {
var name : String!
deinit {
print("Deint AnotherViewController")
}
override func viewDidLoad() {
super.viewDidLoad()
print(CFGetRetainCount(self))
/*
When you test please comment out or vice versa
*/
// // Should not use unowned here. Because unowned is used where not deallocated. or gurranted object alive. If you immediate click back button app will crash here. Though there will no retain cycles
// clouser(string: "") { [unowned self] (boolValue) in
// self.name = "some"
// }
//
//
// // There will be a retain cycle. because viewcontroller has a strong refference to this clouser and as well as clouser (self.name) has a strong refferennce to the viewcontroller. Deint AnotherViewController will not print
// clouser(string: "") { (boolValue) in
// self.name = "some"
// }
//
//
// // no retain cycle here. because viewcontroller has a strong refference to this clouser. But clouser (self.name) has a weak refferennce to the viewcontroller. Deint AnotherViewController will print. As we forcefully made viewcontroller weak so its now optional type. migh be nil. and we added a ? (self?)
//
// clouser(string: "") { [weak self] (boolValue) in
// self?.name = "some"
// }
// no retain cycle here. because viewcontroller has a strong refference to this clouser. But clouser nos refference to the viewcontroller. Deint AnotherViewController will print. As we forcefully made viewcontroller weak so its now optional type. migh be nil. and we added a ? (self?)
clouser(string: "") { (boolValue) in
print("some")
print(CFGetRetainCount(self))
}
}
func clouser(string: String, completion: #escaping (Bool) -> ()) {
// some heavy task
DispatchQueue.main.asyncAfter(deadline: .now() + 5.0) {
completion(true)
}
}
}
If you do not sure about [unowned self] then use [weak self]
You have references that you don’t want to be strong references, in order to avoid circular references. So at some point when the last strong reference to an object gets removed, the object itself gets removed.
What happens to other non-strong references? Obviously they don’t refer to that object anymore, which is problematic. There are two kinds of ways to handle this:
Weak reference. When the last strong reference to an object goes away, all weak references are set to nil, so a developer can check if the referenced object is there anymore. Quite obviously a weak reference must be an optional, otherwise it couldn’t be set to nil. The strategy to use a weak reference: You write “if let ref = weakref”. Either the reference was still there, and since you just assigned it to a strong reference, it will remain until the end of the “if let”. If you don’t do it this way then you may access the same weak reference twice, and it may be (unexpectedly) not nil on the first access, but nil on the second.
You create an unowned reference. If the object goes away, nobody will tell you. It will look as if you have a reference when to the referred object has gone away. You must only use this if you are 100% sure that the referenced object cannot go away early.
Use unowned if you have measured that it is faster, and when you are 100% that you don’t use the rubbish when the object is gone.
Swift has:
Strong References
Weak References
Unowned References
How is an unowned reference different from a weak reference?
When is it safe to use an unowned reference?
Are unowned references a security risk like dangling pointers in C/C++?
Both weak and unowned references do not create a strong hold on the referred object (a.k.a. they don't increase the retain count in order to prevent ARC from deallocating the referred object).
But why two keywords? This distinction has to do with the fact that Optional types are built-in the Swift language. Long story short about them: optional types offer memory safety (this works beautifully with Swift's constructor rules - which are strict in order to provide this benefit).
A weak reference allows the possibility of it to become nil (this happens automatically when the referenced object is deallocated), therefore the type of your property must be optional - so you, as a programmer, are obligated to check it before you use it (basically the compiler forces you, as much as it can, to write safe code).
An unowned reference presumes that it will never become nil during its lifetime. An unowned reference must be set during initialization - this means that the reference will be defined as a non-optional type that can be used safely without checks. If somehow the object being referred to is deallocated, then the app will crash when the unowned reference is used.
From the Apple 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.
In the docs, there are some examples that discuss retain cycles and how to break them. All these examples are extracted from the docs.
Example of the weak keyword:
class Person {
let name: String
init(name: String) { self.name = name }
var apartment: Apartment?
}
class Apartment {
let number: Int
init(number: Int) { self.number = number }
weak var tenant: Person?
}
And now, for some ASCII art (you should go see the docs - they have pretty diagrams):
Person ===(strong)==> Apartment
Person <==(weak)===== Apartment
The Person and Apartment example shows a situation where two properties, both of which are allowed to be nil, have the potential to cause a strong reference cycle. This scenario is best resolved with a weak reference. Both entities can exist without having a strict dependency upon the other.
Example of the unowned keyword:
class Customer {
let name: String
var card: CreditCard?
init(name: String) { self.name = name }
}
class CreditCard {
let number: UInt64
unowned let customer: Customer
init(number: UInt64, customer: Customer) { self.number = number; self.customer = customer }
}
In this example, a Customer may or may not have a CreditCard, but a CreditCard will always be associated with a Customer. To represent this, the Customer class has an optional card property, but the CreditCard class has a non-optional (and unowned) customer property.
Customer ===(strong)==> CreditCard
Customer <==(unowned)== CreditCard
The Customer and CreditCard example shows a situation where one property that is allowed to be nil and another property that cannot be nil has the potential to cause a strong reference cycle. This scenario is best resolved with an unowned reference.
Note from Apple:
Weak references must be declared as variables, to indicate that their
value can change at runtime. A weak reference cannot be declared as a
constant.
There is also a third scenario when both properties should always have a value, and neither property should ever be nil once initialization is complete.
And there are also the classic retain cycle scenarios to avoid when working with closures.
For this, I encourage you to visit the Apple docs, or read the book.
Q1. How is an “Unowned reference” different from a “Weak Reference”?
Weak Reference:
A weak reference is a reference that does not keep a strong hold on
the instance it refers to, and so does not stop ARC from disposing of
the referenced instance. Because weak references are allowed to have
“no value”, you must declare every weak reference as having an
optional type. (Apple Docs)
Unowned Reference:
Like weak references, an unowned reference does not keep a strong hold
on the instance it refers to. Unlike a weak reference, however, an
unowned reference is assumed to always have a value. Because of this,
an unowned reference is always defined as a non-optional type. (Apple Docs)
When to Use Each:
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. (Apple Docs)
Q2. When is it safe to use an “unowned reference”?
As quoted above, an unowned reference is assumed to always have a value. So you should only use it when you are sure that the reference will never be nil. Apple Docs illustrate a use-case for unowned references through the following example.
Suppose we have two classes Customer and CreditCard. A customer can exist without a credit card, but a credit card will not exist without a customer, i.e. it can be assumed that a credit card will always have a customer. So, they should have the following relationship:
class Customer {
var card: CreditCard?
}
class CreditCard {
unowned let customer: Customer
}
Q3. Are “unowned reference” reference an security risk like “dangling pointers” in C/C++
I don't think so.
Since unowned references are just weak references that are guaranteed to have a value, it shouldn't be a security risk in any way. However, if you try to access an unowned reference after the instance that it references is deallocated, you will trigger a runtime error, and the app will crash.
That's the only risk I see with it.
Link to Apple Docs
If self could be nil in the closure use [weak self].
If self will never be nil in the closure use [unowned self].
If it's crashing when you use [unowned self] then self is probably nil at some point in that closure and you probably need to use [weak self] instead.
Check out the examples on using strong, weak, and unowned in closures:
https://developer.apple.com/library/ios/documentation/swift/conceptual/swift_programming_language/AutomaticReferenceCounting.html
Extracts from link
Few Concluding points
To determine if you even need to worry about strong, weak, or
unowned, ask, “Am I dealing with reference types”. If you’re working
with Structs or Enums, ARC isn’t managing the memory for those Types
and you don’t even need to worry about specifying weak or unowned for
those constants or variables.
Strong references are fine in hierarchical relationships where the parent references the child, but not vice-versa. In fact, strong references are the most appropraite kind of reference most of the time.
When two instances are optionally related to one another, make sure
that one of those instances holds a weak reference to the other.
When two instances are related in such a way that one of the
instances can’t exist without the other, the instance with the
mandatory dependency needs to hold an unowned reference to the other
instance.
Both weak and unowned references will not impact the reference count of the object. But weak reference will always be optional i.e. it can be nil, whereas unowned references can never be nil so they will never be optional. When using an optional reference you will always have to handle the possibility of the object being nil. In case of an unowned reference you will have to ensure that the object is never nil. Using an unowned reference to a nil object will be similar to forcefully unwrapping an optional that is nil.
That said it is safe to use an unowned reference where you are sure that the object’s lifetime is more than the reference’s. If that is not the case it is better to use a weak reference instead.
As for the third part of the question, I don’t think unowned reference is similar to a dangling pointer. When we talk about reference count, we usually refer to strong reference count of the object. Similarly swift maintains unowned reference count and weak reference counts for the object (weak reference points to something called a "side table" rather than the object itself ). When the strong reference count reaches zero, the object gets deinitialised, but it cannot be deallocated if the unowned reference count is more than zero.
Now a dangling pointer is something that points to a memory location that has already been deallocated. But in swift since the memory can only be deallocated as long as there is an unowned reference to the object, it cannot cause a dangling pointer.
There are a lot of articles that discuss swift memory management in more detail. Here is one.
Unowned references are a kind of weak reference used in the case of a Same-Lifetime relationship between two objects, when an object should only ever be owned by one other object. It's a way to create an immutable binding between an object and one of its properties.
In the example given in the intermediate swift WWDC video, a person owns a credit card, and a credit card can only have one holder. On the credit card, the person should not be an optional property, because you don't want to have a credit card floating around with only one owner. You could break this cycle by making the holder property on the credit a weak reference, but that also requires you to make it optional as well as variable (as opposed to constant). The unowned reference in this case means that although CreditCard does not have an owning stake in a Person, its life depends on it.
class Person {
var card: CreditCard?
}
class CreditCard {
unowned let holder: Person
init (holder: Person) {
self.holder = holder
}
}
Use unowned when you are sure self can never be nil at the point you accessing self at that point.
Example (you can of course add the target directly from MyViewController, but again, it's a simple example).:
class MyViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let myButton = MyButton { [unowned self] in
print("At this point, self can NEVER be nil. You are safe to use unowned.")
print("This is because myButton can not be referenced without/outside this instance (myViewController)")
}
}
}
class MyButton: UIButton {
var clicked: (() -> ())
init(clicked: (() -> ())) {
self.clicked = clicked
// We use constraints to layout the view. We don't explicitly set the frame.
super.init(frame: .zero)
addTarget(self, action: #selector(clicked), for: .touchUpInside)
}
#objc private func sendClosure() {
clicked()
}
}
Use weak when there is a possibility self can be nil at the point you accessing self.
Example:
class MyViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
NetworkManager.sharedInstance.receivedData = { [weak self] (data) in
print("Can you guarentee that self is always available when the network manager received data?")
print("Nope, you can't. Network manager will be alive, regardless of this particular instance of MyViewController")
print("You should use weak self here, since you are not sure if this instance is still alive for every")
print("future callback of network manager")
}
}
}
class NetworkManager {
static let sharedInstance = NetworkManager()
var receivedData: ((Data) -> ())?
private func process(_ data: Data) {
// process the data...
// ... eventually notify a possible listener.
receivedData?(data)
}
}
Cons of unowned:
More efficient than weak
You can (well, you are forced) to mark the instance as immutable (not anymore since Swift 5.0).
Indicates to the reader of your code: This instance has a relationship to X and it can't live without it, but if X is gone, I am gone too.
Cons of weak:
More safe than unowned (since it can't crash).
Can create a relationship to X that goes in both ways, but both can live without each other.
If you aren't sure, use weak. Wait, I mean ask here on StackOverflow what you should do in your case! Using weak all the time when you shouldn't is just confusing for you and the reader of your code.