[swift-evolution] [Pitch] make @noescape the default

[ilya]

> 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 <
swift-evolution at swift.org> wrote:

>
> > On Dec 19, 2015, at 7:51 PM, Kevin Ballard via swift-evolution <
> swift-evolution at swift.org> 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
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/9f7e1860/attachment.html>