<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 22, 2017, at 3:14 PM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</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 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></div></div></blockquote><div><br class=""></div><div>The requirements I have for the syntax are:</div><div>* it must work with both bound instance method references and closures</div><div>* it must be reasonably concise</div><div>* it must have some relationship to `@guarded` arguments</div><div><br class=""></div><div>The last requirement is the reason I opted for a prefix sigil. The closest parallel we have is `inout` and that uses a prefix sigil. As soon as you decide to use a prefix sigil `?` is the obvious choice for this behavior.</div><div><br class=""></div><div>I am certainly open to hearing alternatives, but they should address each of the three requirements listed above. (I mention this mostly in case anyone else reading does have energy to bikeshed on this).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></div></blockquote><div><br class=""></div><div>Hi David. Thanks for replying! I’m glad you like this approach better. I think I have finally hit on an elegant mechanism for providing safer default semantics for callbacks arguments along with a much more concise syntax for a very widespread pattern. I’ve been thinking about this problem ever since Swift first came out and am pretty pleased with this approach.</div><div><br class=""></div><div>That’s certainly a reasonable way for somebody who really understands what they’re doing to write code. There is an overhead in the weak references and the guards that isn’t necessary in this case. The good news is that this would still be valid code within a guarded closure because the new proposal allows you to override the guarded behavior using the capture list.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""><div class=""><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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></body></html>