Could a guard let `self` = self inside a closure that uses [weak self] cause a crash if the object they reference becomes deallocated? – Ios swift

If the closure holds a strong reference, it prevents the ARC to release the object as long as the closure is still accessible.

The weak and unowned self allow to resolve this strong ownership.
But this means that the object referenced by the closure’s weak self could be deinitailized while the closure could still be called. In this case, the closure’s self would refer to nil.

The guard would in fact just check that the reference is still valid. A nil would make it fail anyway. If it’s a valid reference, it doesn’t change the capture list; you could just assume that self will stay valid until the current execution of the closure returns.

Experimental proof

Here some code to experiment the difference, with a class that traces initialisation and deinitialization, and that can return a closure with self captured:

class T {
    var id:String
    init(_ name:String){
        id = name
        print ("INIT T object (id)")
    }
    func getClosure() -> (Int)->Int {
        return { [weak self] (i:Int) in    
            guard let self = self else {
                print ("Instance vanished")
                return -1
            }
            print (i,self.id)
            return 0
        }
    }
    deinit {
        print ("DEINIT T object (id)")
    }
}

Let’s create the dramatic circumstances where the closure could survive the instance that created it:

var oops:(Int)->Int = {(Int)->Int in 0}

func f1() {
    var t = T("f1_test")
    t.getClosure()(32)       // closure is disposed at the end of the function
}                            // t will be deinitialized in any case
func f2() {
    var t = T("f2_test")
    oops = t.getClosure()    // closure will be kept outside of scope
}                            // t can be disposed only if capture is not strong

f1()
f2()
oops(33)

Let’s analyse what happens. The f1() will result in a T instance that will be deinitialised. This is because the closure is no longer referenced when leaving f1, so the captured self is no longer referenced either, and the ARC will terminate it:

INIT T object f1_test
32 f1_test
DEINIT T object f1_test

The f2() call is more subtle, because the T instance is still referenced by the closure when leaving f2, and the closure survives in a global variable.

If the capture would be strong, you wouldn’t need the guard, since ARC would make sure that the instance is still available. You’d see that the T instance would not be deinitialized.

But since the capture is weak, there is no strong reference to the T instance when returning from f2 and it would be deinitialized properly. So the guard would cause your to get:

INIT T object f2_test
DEINIT T object f2_test
Instance vanished

This proves that the guard let self = self does not replace the closure’s weak capture with a strong one.