[swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[Christopher Kornher]

> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> All object references used within a closure must unwrap successfully for the closure to execute.
> I agree with the logic of this proposal, but this is the confusing part or a part that I slightly disagree with.
> 
> 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.
> 
> On the other hand, when it crashes, it gives him some idea that something's wrong.

Tooling could alleviate some of this mystery. For example:

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.

2) Debugger console commands could be added to describe the execution state of closures in scope and closure variables.

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. 

4) Some runtime switches could be added to enable verbose login modes for closures.

I don’t think that this is an insurmountable problem. There are many features of modern applications that are difficult to debug.

> 
> 
>> 
>> 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?
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/eb20f24d/attachment.html>