@noescape is part of the interface's contract. If you have it for a while (because you had a warning more than because of thoughtful design) then remove it, you're forcing code changes on your clients. I'm not sure it's an appropriate default/warning, at least for public interfaces.
Félix > Le 20 déc. 2015 à 11:14:51, ilya via swift-evolution > <[email protected]> a écrit : > > > 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] <mailto:[email protected]>> wrote: > > > On Dec 19, 2015, at 7:51 PM, Kevin Ballard via swift-evolution > > <[email protected] <mailto:[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] <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 > > <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 > <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
