<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=""><div class="">-1</div><div class="">I support improvements in this area but I do not think that adding guarded closures will fix the case.</div><div class="">It raises multiple concerns:</div><div class="">- prepending ? to the closure declaration is as forgettable as `[weak self]`</div><div class="">- reactive programming often assumes chaining of operations. How guarded closures affect next operations in the chain?</div><div class="">- the closure must exist until either the control deallocates (source of actions) or self deallocates (destination of actions). Guarded closure will not provide an expected behavior</div><div class="">- managing lifecycle of nested guarded closures could be complex to understand and implement into the language</div><div class="">- why would you consider using @escaping instead of @guarded?</div><div class=""><br class=""></div><div class="">I personally prefer doing something like this:</div><div class=""><br class=""></div><div class="">```swift</div><div class="">self.button.onAction(forEvents: [.touchUpInside], context: self) { (self, sender, event) in</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>self.performSearch(query: self.searchField.text)</div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">or</div><div class=""><br class=""></div><div class="">```swift</div><div class="">self.button.actions(forEvents: [.touchUpInside])</div><div class=""> .debounce(interval: 3.0)</div><div class=""> .map(context: self) { (self, _) in</div><div class=""> return self.searchField.text</div><div class=""> }</div><div class=""> .distinct()</div><div class=""> .onUpdate(context: self) { (self, searchQuery) in</div><div class=""> self.performSearch(query: searchQuery)</div><div class=""> }</div><div class="">```</div><div class=""><br class=""></div><div class="">This code neither requires an addition of language features nor contains retain cycles. All closures will be released as soon as source or destination deallocates.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Feb 22, 2017, at 22:57, Matthew Johnson 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div 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 class=""><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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></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=""></body></html>