<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi David,<div class=""><br class=""></div><div class="">I just shared a draft proposal to introduce guarded closures last week: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html</a>. I think you would find it very interesting.</div><div class=""><br class=""></div><div class="">I considered including a new capture list specifier `guard` in this proposal but decided against it. Guarded behavior requires prefixing the contents of the closure with a guard clause that returns immediately if the guard is tripped. This is a property of the closure as a whole, not of an individual capture. For that reason, I decided that allowing a `guard` specifier for an individual capture would be inappropriate. </div><div class=""><br class=""></div><div class="">Instead, a guarded closure has a guarded by default capture behavior which can be overridden with `weak`, `unowned` or `strong` in the capture list. The thread on this proposal was relatively brief. I plan to open a PR soon after making a few minor modifications.</div><div class=""><br class=""></div><div class="">Matthew</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 22, 2017, at 2:48 PM, David Hedbor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><span style="font-size:12.8px" class="">Hello,</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">(apologies if this got sent twice - gmail and Apple mail seems to confused as to what account the first mail was sent from)</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">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.</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">Problem:</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">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:</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class=""> { [weak self] in self?.execute() }</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">This is simple enough but often doesn’t work:</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">{ [weak self] in self?.boolean = self?.calculateBoolean() ]</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">This fails because boolean is not an optional. This in turn leads to code like this:</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">{ [weak self] in</span><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class=""> guard let strongSelf = self else { return }</span><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class=""> strongSelf.boolean = self.calculateBoolean() }</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">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.</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">Solution:</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">Instead of using unowned or weak, let’s use guard/guarded syntax:</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">{ [guard self] in</span><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class=""> self.isExecuted = self.</span><span style="font-size:12.8px" class="">onlyIfWeakSelfWasCaptured<wbr class="">()</span><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">}</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">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:</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">{ [weak self] in</span><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class=""> guard let strongSelf = self else { return }</span><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class=""> strongSelf.isExecuted = strongSelf.</span><span style="font-size:12.8px" class="">onlyIfWeakSelfWasCa<wbr class="">ptured()</span><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">}</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">Except with a lot less boilerplate code, while not losing any clarify in what it does.</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">Impact / compatibility:</span><br style="font-size:12.8px" class=""><br style="font-size:12.8px" class=""><span style="font-size:12.8px" class="">This is simply additive syntax, and wouldn’t affect any existing code.</span><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>