> If we don’t change the default maybe we should at least add a warning when you *could* add @noescape but didn’t. A lot of folks are likely to leave it off when they should really be adding it.
I like this idea. We have a warning for variables that can be made into let, so why not this? On Sun, Dec 20, 2015 at 18:50 Matthew Johnson via swift-evolution < [email protected]> wrote: > > > On Dec 19, 2015, at 7:51 PM, Kevin Ballard via swift-evolution < > [email protected]> wrote: > > > > -1 > > > > The standard library is not representative of how closures are commonly > used. Notably, the standard library never executes anything asynchronously > (an extremely common use of closures in apps), doesn't ever hold closures > that are triggered later by a separate event (e.g. NSNotificationCenter > observing, or UIAlertView handlers, or any third-party solution for > block-based target/action replacement), no timers, no completion handlers, > etc. The only constructs in the standard library that come to mind that > would need escaping closures are lazy sequence operations and AnySequence > (I haven't actually looked to see if there are any others). But nearly all > uses of closures in UIKit require escaping, nearly all uses of closures in > libdispatch require escaping, and I wager that nearly all uses of closures > in application code require escaping. > > Those are fair points. The right place to look is in application code so > my skimming of the library was probably not that relevant. > > The fact that the compiler would tell you when you need @escaping but > doesn’t tell you when you could add @noescape is part of what prompted my > pitch. If we don’t change the default maybe we should at least add a > warning when you *could* add @noescape but didn’t. A lot of folks are > likely to leave it off when they should really be adding it. > > It would be interesting to look at function arguments in application code > written in different styles (OO vs mixed vs functional-leaning) and see > what the split is for escaping vs non-escaping function arguments. > > > > > -Kevin Ballard > > > > On Sat, Dec 19, 2015, at 12:10 PM, Matthew Johnson via swift-evolution > wrote: > >> @noescape is safer because it does not require thinking about lifetime > issues for captured objects. My hunch was that @noescape (or @autoclosure > with implies @noescape) is also more common. I had a look through the > standard library and this is definitely the case there. > >> > >> What does everyone think about making @noescape the default and > introducing @escaping (or something similar) to annotate function arguments > that do escape the call stack? > >> > >> Matthew > >> _______________________________________________ > >> swift-evolution mailing list > >> [email protected] > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
