<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Big -1<div class=""><br class=""></div><div class="">Consider the following</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">//somewherelse.swift</div><div class=""><br class=""></div><div class="">var strongReference: Foo! = nil</div><div class="">func evil(foo: Foo) {</div><div class=""> strongReference = foo</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">and</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">//Foo.swift</div><div class="">class Bar {</div><div class=""> var f: Foo</div><div class=""> dispatch_async(queue) { [strong self] in</div><div class=""> evil(f)</div><div class=""> }</div><div class="">}</div></blockquote><div class=""><br class=""></div>IMHO, `evil(self.f)` is *far* better and *far* more likely to look like a bug. I feel so strongly about this that I would take the extraordinary step of banning `strong self` from my codebase. I have spent waaaaaaay too much time playing "spot func evil".<div class=""><br class=""><div class=""><div class="">Obviously reasonable people can disagree about "more likely" but "this sort of retain cycle creep" is how we ended up with the problems in <a href="http://sealedabstract.com/code/nsnotificationcenter-with-blocks-considered-harmful/" class="">this post</a>, and one of the secret advantages of Swift is those bugs are SO MUCH HARDER.</div><div class=""><br class=""></div><div class="">Additional compiler diagnostics may help here, (which I want to see regardless) but unless those come in as part of the same proposal I'm -1.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 15, 2015, at 5:02 PM, Greg Parker 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="">Swift currently requires that `self` be used explicitly inside closures, to help avoid bugs from unintentional capture. This is annoying when a closure uses `self` a lot. Closures should be allowed to name `[strong self]` in their capture list and thereafter not be required to write `self` everywhere.<br class=""><br class="">I wrote code this weekend that looked something like this:<br class=""><br class=""> data = ...<br class=""> running = true<br class=""> delegate.notifyBegin(data)<br class=""><br class=""> dispatch_async(queue) {<br class=""> self.processData(self.data)<br class=""> self.running = false<br class=""> self.delegate.notifyEnd(self.data)<br class=""> }<br class=""><br class="">Note the asymmetry: the dispatched code needs to use `self` and the non-dispatched code does not. It is clear that the dispatched closure captures `self`, but it's annoying that it needed to be mentioned five different times. The noise gets worse with longer closures. The annoyance gets worse when moving code in and out of dispatches or other closures, with lots of editing required each time.<br class=""><br class="">The proposal would allow the same code to be written like this:<br class=""><br class=""> data = ...<br class=""> running = true<br class=""> delegate.notifyBegin(data)<br class=""><br class=""> dispatch_async(queue) {<br class=""> [strong self] in<br class=""> processData(data)<br class=""> running = false<br class=""> delegate.notifyEnd(data)<br class=""> }<br class=""><br class="">Advantages:<br class="">* The dispatch'ed code looks like the non-dispatched code. <br class="">* The capture of `self` is still obvious.<br class="">* The code's action is clearer without the `self` noise.<br class=""><br class="">Disadvantages:<br class="">* The capture behavior of self's properties is less obvious. For example, neither closure above captured its own copy of `self.data`, but that behavior is not immediately visible in the second closure.<br class=""><br class=""><br class="">What about [weak self] and [unowned self] ? I do not propose to change the `self` requirement for those closures. In the weak case it is critically important to know where `self` is accessed, because it could potentially become nil between any two accesses. Unowned self might be reasonable to change, but for simplicity I won't do so here.<br class=""><br class=""><br class="">-- <br class="">Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler<br class=""><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></div></body></html>