<div dir="ltr">My 2c:<div><br></div><div>This proposal is made more appealing to me because it is not simply a &#39;beginners will get confused&#39; 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&#39;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><br></div><div>To spin off of Christopher&#39;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 &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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&#39;t be invoked if all captured variables can&#39;t be unwrapped, which is definitely confusing to the newcomer (to whom this is partially targetted as you&#39;ve mentioned) if he puts a breakpoint in it and doesn&#39;t get executed even when he&#39;s explicitely invoking it somewhere.</div><div><br></div><div>On the other hand, when it crashes, it gives him some idea that something&#39;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>