<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 Jun 27, 2016, at 2:35 PM, L. Mihalkovic 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 dir="auto" class=""><div class=""><br class=""><br class=""><div class="">Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div class=""><br class="">On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">My 2c:<div class=""><br class=""></div><div class="">This proposal is made more appealing to me because it is not simply a 'beginners will get confused' issue. </div><div class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">I have written tens of thousands of lines of Swift from Swift 1 to the Swift 3 preview and I still can't shake occasionally accidentally capturing `self` strongly when I, for example, assign a closure as a listener/action to a UI component.</span><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">The problem of is that it is easier for an app to survive an accidental extra capture than it is for it the survive a missing one.. So if this is really for beginners, then it is much better to keep the current behavior which will lead them to have leaky apps, than it is to give them apps whre objects will vanish from under their feet... granted neither is good to begin with.</div></div></div></blockquote><div><br class=""></div>For many cases, that is exactly the behavior you want. In my experience, the instances of closures being the only live reference to objects not being constructed by the closure are rare. </div><div><br class=""></div><div>To clarify, the proposed implicit guard statements would create strong references once the closure starts executing, so referenced objects would not disappear during the execution of the closure. </div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">To spin off of Christopher's last email, my proposal is thus: we could include the original proposal (without numbered addendums) and use tooling, but have it alleviate the burden another way: have the tooling insert `[strong self]` by default when autocompleting a block.</div><div class=""><br class=""></div><div class="">BTW, @Manuel Krebber: this proposal would not affect your run-of-the-mill map statement. array.map { object in object.property } requires no explicit capture since object is intuitively strongly captured there.</div><div class=""><br class=""></div><div class="">What do we think? Worth discussing?</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jun 27, 2016 at 12:10 PM Christopher Kornher via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div style="word-wrap:break-word" class=""><ol style="list-style-type:lower-alpha" class=""><span style="font-size:10.8px" class="">All object references used within a closure must unwrap successfully for the closure to execute.</span></ol></div></blockquote><div class="">I agree with the logic of this proposal, but this is the confusing part or a part that I slightly disagree with.</div><div class=""><br class=""></div><div class="">By this logic, the block won't be invoked if all captured variables can't be unwrapped, which is definitely confusing to the newcomer (to whom this is partially targetted as you've mentioned) if he puts a breakpoint in it and doesn't get executed even when he's explicitely invoking it somewhere.</div><div class=""><br class=""></div><div class="">On the other hand, when it crashes, it gives him some idea that something's wrong.</div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">Tooling could alleviate some of this mystery. For example:</div><div class=""><br class=""></div><div class="">1) In Xcode and other GUIs, closures that will not be executed could be greyed-out, perhaps with the reason overlaid on the closure perhaps this would only happen when a breakpoint was set within the closure. Perhaps the app could break on the on breakpoints within non-executing closures and notify the user that the closure did not execute.</div><div class=""><br class=""></div><div class="">2) Debugger console commands could be added to describe the execution state of closures in scope and closure variables.</div><div class=""><br class=""></div><div class="">3) Debug apps could bottleneck all closures through a function that that can be break-pointed. Breakpoints could be edited to filter on specific closures. </div><div class=""><br class=""></div><div class="">4) Some runtime switches could be added to enable verbose login modes for closures.</div><div class=""><br class=""></div><div class="">I don’t think that this is an insurmountable problem. There are many features of modern applications that are difficult to debug.</div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div style="word-wrap:break-word" class=""><ol style="list-style-type:lower-alpha" class="">
</ol><div style="margin:0px;font-size:10.8px;line-height:normal;min-height:12px" class=""><span class=""></span><br class=""></div><div style="margin:0px;font-size:10.8px;line-height:normal" class=""><span class="">I believe that these are safe, sensible and understandable rules that will eliminate the need for capture lists for many closures. What do you think?</span></div><div style="margin:0px;font-size:10.8px;line-height:normal;min-height:12px" class=""><span class=""></span><br class=""></div><div style="margin:0px;font-size:10.8px;line-height:normal;min-height:12px" class=""><span class=""></span><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></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=""></blockquote></div><br class=""></body></html>