4

If you have a Dog with a weak reference to Bone, that means that the Dog is the 'owner' of the reference in this situation, and it USES bone, but bone can go out of existence and Dog can still function (because the reference to bone is an optional).

However with 'unowned', it seems to be that the keyword 'unowned' is used not in the owner's declaration of the reference, but in the other object. For instance, Bone's reference to its dog is marked as 'unowned'.

Unowned is not safe. It can crash if the owner goes out of existence at some point in the program, and it cannot be an optional. Why would one ever use unowned as opposed to a weak reference?

Why not just use weak? from my understanding it just has to do with failing loudly vs. failing silently. In the case of an unowned, the app will always crash if bone ends up without a dog, whereas if we use weak, you will end up with a bone that still exists, with a 'ghost' dog.

Ahmad F
  • 30,560
  • 17
  • 97
  • 143
user7024499
  • 951
  • 1
  • 10
  • 24

1 Answers1

21

Strong & Weak references

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.

So when A has a weak reference to B, then A is NOT the owner.

Example (where A is Bone and B is Dog)

class Dog {
    var bone: Bone?
}

class Bone {
    weak var belongsTo: Dog?
}

Strong Reference

Here a Dog can have a Bone. In that case it's the owner of that Bone. So the bone property is a strong reference.

Weak reference The Bone can belong to a Dog. But we need to declare the belongsTo property as weak, otherwise we have a strong retain cycle (which means ARC is not going to release these object once we are done with them).

Important: In this scenario a Dog can exists without a Bone. And a Bone can exists without a Dog.

Unowned reference

Let's look at another example

class Person {
    var creditCard: CreditCard?
}

class CreditCard {
    unowned var owner: Person

    init(owner: Person) {
        self.owner = owner
    }
}

Again, Person can own a CreditCard, so it has a the owner property which is a strong reference to CreditCard.

However a CreditCard CANNOT exist without a person. Right? So inside CreditCard we want a property which will always be populated but we also want it to be weak.

Something like this

weak var owner: Person 
error: 'weak' variable should have optional type 'Person?'

However a weak property must be declared as Optional so we use the unowned which means:

I want a weak reference and it will always be populated.

Luca Angeletti
  • 58,465
  • 13
  • 121
  • 148
  • 1
    So let me get this straight. Using weak, the owner can still persist even if the reference it has a weak reference to is deleted. However, with unowned, its the other way around...The 'owner' AKA the person, can exist without the credit card, but an error will occur and crash the program if the person is deleted before the credit card. True? – user7024499 Nov 27 '16 at 15:25
  • 2
    @user7024499: Exactly – Luca Angeletti Nov 27 '16 at 15:30
  • 1
    And just to finally understand, in your credit card example, the credit card instance cannot be deleted from memory while the person instance is still in memory using it... USUALLY. However, because of the keyword unowned, it is saying that if this credit card goes out of memory, it is okay, as long as it goes out of memory first before the person. – user7024499 Nov 27 '16 at 15:40
  • 1
    @user7024499 CreditCard will not be deallocated because Person has a strong reference to it. – Luca Angeletti Nov 27 '16 at 16:09
  • 2
    @user7024499 However if you set person.creditCard to nil then CreditCard gets deallocated. So you can have a Person without a CrediCard. On the other hand a `CreditCard` must always have a `Person` associated because you cannot have a `CreditCard` without a `Person`. – Luca Angeletti Nov 27 '16 at 16:15