[swift-evolution] [Proposal] Make non-escaping closures the default

[Trent Nadeau]

When would be a good time to actual put out a PR to the swift-evolution
repo for this proposal? The feedback so far has been very light, but I'm
not sure if that's because everyone's gearing up for WWDC, if there's
little interest, or if it's uncontroversial.

On Wed, Jun 8, 2016 at 1:17 PM, John McCall <rjmccall at apple.com> wrote:

> > On Jun 7, 2016, at 7:25 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
> >> @escaping would be part of the parameter type just as @noescape is
> today. Your foo(closure:) example wouldn't compile with my proposal, the
> same as today if you marked the parameter with @noescape. Non-escaping
> function parameters are only allowed to be called. They can't be assigned
> to variables.
> >
> > Okay, that does correct that issue. Although it raises a separate issue:
> a bare closure type now means something different in a parameter list than
> anywhere else.
>
> @escaping is really a parameter-specific aspect of the outer function
> type, not an aspect of the parameter's type.  It's just like something like
> NS_CONSUMED in Objective-C ARC.
>
> John.
>
> > Are generic types which happen to be functions in some particular use
> automatically @escaping? Are typealiases and associated types automatically
> @escaping?
> >
> > Also, if `@escaping` is a part of the parameter list syntax (like
> `inout`) instead of the type syntax (like `@autoclosure`), would it make
> sense to drop its `@` sign to make them more syntactically similar?
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160609/de26d5b3/attachment.html>