> On Jun 27, 2016, at 11:52 PM, Charlie Monroe via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jun 27, 2016, at 9:10 PM, Christopher Kornher <ckorn...@me.com >> <mailto:ckorn...@me.com>> wrote: >> >> >>> On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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. > > 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…
This technique is used with CoreData, OS X Bindings, and probably other frameworks and yes, it is often a tool of last resort. Tools like grep and spunk are often needed to make use of the output, but this is an effective technique, if not a very efficient one. I much prefer interactive debugger support. One advantage of global logging options is that they can be to used over long periods, on remote machines to capture infrequent errors. > >> >> 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@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
