Pitch: Syntactic sugar for circumventing closure capture lists

Sometimes you want to keep the object alive until the callback happens.

For example if you have an object that takes significant time to serialize & save you might want to dispatch_async that to to some background queue and serialize and store it. I would expect that most dispatch_async uses actually want to extend the lifetime of whatever they capture.

Objects participating in some sort of network RPC might want to live long enough for the existing set of outstanding calls to complete (or timeout) and handle the replies. I wouldn't say "most" of these want to extend the lifetimes of any captured objects, but a lot do...or at least frequently wouldn't cause problems.

Sadly we don't have a way to annotate function arguments as "will escape, but has a short lifetime", nor do we even really have a good definition of "short". Does a 0.1 second timer count as "short"? Does the same timer count as short if the target queue might be suspended? Is "when the RPC completes" soon?

That said if weak were the default you will get reminded as soon as you get an "need to unwrap" reminder that you ought to either unwrap the value, or change the capture list to capture self strongly.

1 Like