Swift 3: capture strong self in @escaping closure without asynchronous work

Question

There is a protocol with the following declaration:

typealias SuggestionSourceCallback = ([Suggestion]) -> ()

protocol SuggestionSource {
    func suggest(_ query: SuggestionQuery, callback: @escaping SuggestionSourceCallback)
}

Two classes implement this protocol. First class obtains suggestions asynchronously (via GCD)

final class FisrtClass: SuggestionSource {
    private let queue = DispatchQueue(label: "my.app.queue", attributes: [])
    private var lastQuery: SuggestionQuery?
    // ...
    func suggest(_ query: SuggestionQuery, callback: @escaping SuggestionSourceCallback) { 
        self.queue.async { [weak self] in

            // capturing strong self
            guard let strongSelf = self else {
                return
            }

            // referencing self here, for example
            guard self.lastQuery == query else {
                return
            }

            // suggestions is a local variable
            var suggestions: [Suggestion] = []

            // ... 

            DispatchQueue.main.async {
                callback(suggestions)
            }
        }
    }
}

...while second class does it synchronously

final class SecondClass: SuggestionSource {
    // ...
    func suggest(_ query: SuggestionQuery, callback: @escaping SuggestionSourceCallback) {
        // ...
        callback(self.suggestions[query])
    }
}

My questions are:

1. should I capture strongSelf in FirstClass's implementation?
2. should I capture strongSelf in SecondsClass's implementation?

UPDATE

Additional question. Suppose SecondClass has its suggestions as a static let, what pattern in this case would be?

final class SecondClass: SuggestionSource {
    static let suggestions: [String: [SuggestionQuery]] = {
         // ...
    }()

    // ...
    func suggest(_ query: SuggestionQuery, callback: @escaping SuggestionSourceCallback) {
        // ...
        callback(self.suggestions[query])
    }
}

Answer 1

In SecondClass, there is no need to create a strongSelf variable. Where would you put it? The point is that self is guaranteed not to be nil anyway because you are running within the scope of one of its methods.

The same is true of your additional question, but for a different reason. suggestions is now static, so prefixing with self is a matter of syntax, (I am presuming you meant to also prefix the suggest method with static).

However, in FirstClass, there is a subtle difference between capturing strongSelf and not capturing it.

Because you are using [weak self], self could be nil when you enter that block so you need to check against that anyway. One way is to repeatedly use optional chaining, i.e.:

self?.doSomething()
self?.doSomethingElse()

This is saying:

If I have a reference to self, do something. If I still have a reference to self, do something else.

By adding a strongSelf variable:

guard let strongSelf = self else {
  return
}
strongSelf.doSomething()
strongSelf.doSomethingElse()

...you are saying:

do something and do something else if you have a reference to self, otherwise do nothing.

So, you guarantee that if the first thing happens, so does the second. The approach you take is going to depend on your application.

Answer 2

Scenario 1 is a good candidate for [unowned self].

In this case if the queue exists, so does self, therefore it is safe to reference self without retaining it.

Note: You should only use unowned when you can be sure that the block's lifecycle is directly tied to the captured variable. In other cases unowned can cause interrmittent crashes (which are really hard to debug).

Also unowned is more performant than weak so should be preferred where it is safe to use either source.

For scenario 2, self is not captured by any block that I can determine so you shouldn't need to worry at all about it.

For the update, you still don't capture self, the closure that defines the suggestions dictionary should be executed as soon as it is called.