[swift-evolution] [Proposal] Guarded self in closures

David Hedbor neotron at gmail.com
Wed Feb 22 14:48:44 CST 2017


Hello,

(apologies if this got sent twice - gmail and Apple mail seems to confused
as to what account the first mail was sent from)

I’m new to this mailing list, but have read some archived messages, and
felt that this would be a reasonable subject to discuss. It’s somewhat
related to the recent posts about @selfsafae/@guarded but distinctly
different regardless.


Problem:

It’s often desirable not to capture self in closures, but the syntax for
doing so adds significant boilerplate code for [weak self] or us unsafe
when used with [unowned self]. Typically you’d do something like this:

  { [weak self] in    self?.execute() }

This is simple enough but often doesn’t work:

{ [weak self] in self?.boolean = self?.calculateBoolean() ]

This fails because boolean is not an optional. This in turn leads to code
like this:

{ [weak self] in
   guard let strongSelf = self else { return }
   strongSelf.boolean = self.calculateBoolean()  }

And this is the boilerplate code. My suggestion is to add a syntax that
works the same as the third syntax, yet doesn’t require the boilerplate
code.


Solution:

Instead of using unowned or weak, let’s use guard/guarded syntax:


{ [guard self] in
   self.isExecuted = self.onlyIfWeakSelfWasCaptured()
}

In essence, guarded self is equivalent to a weak self, that’s captured when
the closure is executed. If it was already released at that point, the
closure is simply not executed. It’s equivalent to:

{ [weak self] in
   guard let strongSelf = self else { return }
   strongSelf.isExecuted = strongSelf.onlyIfWeakSelfWasCaptured()
}

Except with a lot less boilerplate code, while not losing any clarify in
what it does.

Impact / compatibility:

This is simply additive syntax, and wouldn’t affect any existing code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170222/78e6cbff/attachment.html>


More information about the swift-evolution mailing list