Pitch: Syntactic sugar for circumventing closure capture lists

Whoa, hang on. I think it's a jump to say [unowned self] is safer than [strong self], and [weak self] + guard + return definitely isn't safer because it leads to silently ignoring results (and silently ignoring failures).

I'm really curious what cases you all are using [weak self] with so much that you want sugar for it. [unowned self] I get because you want to avoid reference cycles, but [weak self] implies that self might go away before the callback finishes, and, like, shouldn't you know if that's going to happen?

EDIT: [strong self] has benefits for a default because it's consistent with the behavior for structs that contain references.

6 Likes