-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.
-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
