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

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.

When you write a closure like this:

{ [weak self] in
    guard let self = self else { return }
    ...
}

You are checking that the class in which this closure is declared is still allocated, if that class is still allocated you are creating a new strong reference to it inside the closure itself.

You do that because if all other strong reference to the class are deleted there will still be the strong reference created in

guard let self = self else { return }

At that point you can be sure that until the end of the closure the class in which the closure is declared is allocated, because the reference is in the closure itself.

So, to answer your question, no, if you write

guard let self = self else { return }

that closure can't crash because you have a strong reference that's still alive.

Different thing is if you use [unowned self]. Unowned self is like an unwrapped optional. If you use it without checking its existence you are implicitly writing

self!.<something>

so if the self is deallocated when you call that closure it will crash.