`guard` capture specifier for closure capture lists

[ExFalsoQuodlibet (Elviro Rocca)]

@Karl

No, it depends on what you were going to do on the other branch. When you refer to another object in a callback, there are really only 3 things you can do with it:

• Read a value
• Write a value
• Call a function

Now, there are circumstances where you were going to read a value (and couldn't capture it in advance), but you literally don't care if that data exists or not, or you were going to write a value, but actually it is truly optional and really nothing changes regardless if that storage location still exists, or were going to call a function, but you don't care if your callback ends up screaming in to the void - but those tend to be the exception.

The more usual case is that you take actions for a reason - you needed that data, or some other object needed that function call, and without it, your application ends up doing nonsensical things.

I'm not sure these tend to be the exception, especially with UI handlers, which are one the most frequent usages of [weak self]. I'm not sure about this, but you might be referring to a case where a callback is stored by object A (and references self) but is executed by object B, that assumes that object A will do something when the callback is executed: if this is the case, I think this is simply not a good solution to this kind of problem. In general, code that "assumes" that things will happen at a distance – because some function is called – can get out of control (and become impossible to understand) very easily. A value should be returned from that callback, signaling what happened, or returning the needed information, and in the case of entering the else branch of a guard, the callback could return nil, a specific value that describes the situation, like a failed Result, or even throwing, so the caller can understand what happened without making unwarranted assumptions.

But this is just a specific case: my point is, on a case-by-case basis there's (usually) always a choice, and there's always a way to preserve useful information, in order to offer the user a good experience.

@Karl

This is the key point where we differ: my belief is that crashing is not solely a user experience matter, or that user experience doesn't mean what you think it means.

There are far worse things you can do than crashing, and an application which finds itself in a state its creators never envisioned could quite easily end up destroying data, draining the user's battery, purchasing things which cost the user real money, leaking their private information, etc. Would you really consider hobbling along, praying that those things don't happen, to be a better user experience than crashing? Try asking your users what they think.

I think the point were we differ is that you're opposing a crash to a bunch of terrible consequences, while I think that's a false dichotomy. I agree that crashing is better than the scenarios you envisioned, but there are alternatives that would offer a better, more informative experience to the user, while also being sufficiently informative to the developer. But what I actually see in the field is a lot of developers that think that [unowned self] (or force unwrapping in general) is an ok default, and are completely misled on this: that is exactly the pattern that leads a team to not really think about what they're doing, while using users as beta (or rather, alpha) testers for their "product".

@Karl

Yeah, sometimes it's thankless - because users should be able to take it for granted. You don't thank every driver for not hitting you with their car.

I think this analogy is completely wrong: a crashing app is not a driver that hits you, but a car that turns off randomly while driving. The consequences, of course, are different, but the underlying concept is: you're using a product that fails while you're using it, that kicks you out and leaves you confused.