<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 Matthew,<div class=""><br class=""><div class="">Finally found time to read the proposal. Much better than the previous iterration. I’m not a huge fan of the proposed syntax either but don’t have the energy for bike shedding :)</div><div class=""><br class=""></div><div class="">As a side note, I’d like to say that I would not use this very often. I much more often use <b class="">unowned</b> capture variables when its clear that the closure can’t outlive the captured variable. For example, my code often looks like this:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">class MyViewController : UIViewController {<br class=""> var button: ActionButton!<br class=""> <br class=""> override func viewDidLoad() {<br class=""> super.viewDidLoad()<br class=""> <br class=""> button.addAction { [unowned self] in<br class=""> print("self: \(self)")<br class=""> }<br class=""> }<br class="">}</font></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 20 Feb 2017, at 18:01, 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=""><div class=""><br class=""><blockquote type="cite" class="">On Feb 20, 2017, at 8:33 AM, Florent Bruneau <<a href="mailto:florent.bruneau@intersec.com" class="">florent.bruneau@intersec.com</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">Le 20 févr. 2017 à 06:35, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""><br class=""><blockquote type="cite" class="">On Feb 19, 2017, at 2:57 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">A guarded closure may be created by prefixing a bound instance method reference with the `?` sigil:<br class=""><br class="">```swift<br class="">let guarded = ?myObject.myMethod<br class=""><br class="">// desugars to:<br class="">let guarded = { [weak myObject] in<br class="">guard let myObejct = myObject else {<br class=""> return<br class="">}<br class="">myObject.myMethod()<br class="">}<br class="">```<br class=""></blockquote><br class="">I like this in principle, but I don't like the syntax. The `?` is cryptic and looks pretty strange in prefix position. I think what I'd like to see is:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let guarded = weak myObject.myMethod<br class=""></blockquote><br class="">I like the idea of weak closures even if this may conflict with the fact closures are already internally refcounted object. While we cannot have weak references to closure in the language, using `weak` might be misleading in some ways.<br class=""><br class="">In term of syntax, the `weak` keyword looks nice (much better than the '?' and @guarded once). The weak could be used on both sides.<br class=""><br class="">```swift<br class="">addAction(action: weak Action)<br class="">addAction(action: weak myAction)<br class="">```<br class=""><br class="">However, I think this might still look weird with inlined closures, in particular in case you use the suffix syntax for closures:<br class=""><br class="">```swift<br class="">addAction() weak {<br class=""> /* */<br class="">}<br class="">```<br class=""></blockquote><br class=""><br class="">We wouldn’t want to use `weak` if this has the guarded behavior I proposed. We could use `guarded` though.<br class=""><br class="">There are a couple of important things enabled by having the language implement the guarded behavior. <br class=""><br class="">First, the implementation could release the entire closure context as soon as one of the guarded captures is released. This is not possible if users write the code out manually. Second, in the future directions I discuss allowing libraries to detect that the guard has been triggered and the closure has become a no-op. This is also not possible when users write the guard out manually and would be quite desirable for libraries that want to discard their reference to the closure after it becomes a no-op.<br class=""><br class="">_______________________________________________<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></div></blockquote></div><br class=""></div></div></body></html>