<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br><div>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><br>On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">My 2c:<div><br></div><div>This proposal is made more appealing to me because it is not simply a 'beginners will get confused' issue. </div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">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></div></div></div></blockquote><div><br></div><div>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><br></div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>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><br></div><div>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><br></div><div>What do we think? Worth discussing?</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 27, 2016 at 12:10 PM Christopher Kornher via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></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"><div><blockquote type="cite"><div>On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><ol style="list-style-type:lower-alpha"><span style="font-size:10.8px">All object references used within a closure must unwrap successfully for the closure to execute.</span></ol></div></blockquote><div>I agree with the logic of this proposal, but this is the confusing part or a part that I slightly disagree with.</div><div><br></div><div>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><br></div><div>On the other hand, when it crashes, it gives him some idea that something's wrong.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Tooling could alleviate some of this mystery. For example:</div><div><br></div><div>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><br></div><div>2) Debugger console commands could be added to describe the execution state of closures in scope and closure variables.</div><div><br></div><div>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><br></div><div>4) Some runtime switches could be added to enable verbose login modes for closures.</div><div><br></div><div>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"><div><div><br></div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><br></div><br><blockquote type="cite"><div style="word-wrap:break-word"><ol style="list-style-type:lower-alpha">
</ol><div style="margin:0px;font-size:10.8px;line-height:normal;min-height:12px"><span></span><br></div><div style="margin:0px;font-size:10.8px;line-height:normal"><span>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"><span></span><br></div><div style="margin:0px;font-size:10.8px;line-height:normal;min-height:12px"><span></span><br></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></blockquote></div><br></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>