The example in “Variable Capturing” seems to have several errors, and the discussion of the issue is quite confusing and inadequate.
The line BNRItemCell *strongCell = weakCell; is trying to solve a problem that doesn’t exist.
The block is called by the cell, on the main thread; any recycling or deallocing of the cell would also happen on the main thread—thus the block has to complete before this can happen! The scenario that the strongCell reference is trying to solve just doesn’t exist. Moreover, this is the norm in this kind of code. Because all of the critical sections are on the main thread, concurrency is typical not a major concern—it has to be executed serially.
Furthermore, the strongCell is never checked for nil, so if there was a race condition, the presented solution wouldn’t solve it! Creating the strong reference earlier in the block than the call to convertRect:fromView: that references it does nothing to ensure that the weak reference was still intact when the strong reference was created. If there were a race condition, either a lock needs to be taken prior to entering the critical section—standard concept for dealing with race conditions; or—the likely solution in this case—the strong reference needs to be checked after it ensures that the cell cannot be dealloced.
Of course, in almost all cases (possibly in all cases—in practice that seems to be the case), a reusable table view cell is only dealloced when the table view is; in this case, the block has a strong reference to the view controller, which has a strong reference to the table view. So, main-thread issues aside, what could cause the cell do be dealloced is a total mystery. That said, the more likely scenario, if there wasn’t the whole main-thread synchronization issue, is that the cell is recycled—and a strong reference would do nothing to prevent or detect this.
Finally, in context for someone just seeing these issues for the first time, the example is just confusing. It is in no way explicit that the concern is a race condition, or anything having to do with concurrency. Those are involved topics, so covering them in depth seems impractical. But treating them as issues that are typically a concern is also problematic; in practice, these are rarely problems for code that is dealing with anything UIKit-related—it’s all serialized on the main thread.
Simply introducing the weak reference on its own and talking about the retain cycle seems like enough information; no need to muddy the waters with an advanced, tangential discussion. That could be relegated to a “For the More Curious”, where several paragraphs could be used to talk about race conditions. Also, mentioning that anything UI-related typically depends on the main thread and so doesn’t need to concern itself with these race conditions seems very appropriate.