> On Jun 27, 2016, at 9:10 PM, Christopher Kornher <[email protected]> wrote: > > >> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution >> <[email protected] <mailto:[email protected]>> 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.
This can solve issues that you may have with a 2KLOC project that does nothing but waits for the user to click on something. When you have a project of 100KLOC, running at 100% CPU on a background thread, I don't think you'd debug anything since console would be flooded by thousands of log messages... > > 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
