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

[John McCall]

> On Jun 9, 2016, at 3:17 PM, Trent Nadeau <tanadeau at gmail.com> wrote:
> 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.

The initial feedback phase is intended for discussion which shapes the basic content of a proposal, e.g. exploring the goals, suggesting different ways of achieving those goals, etc.  Specifically, it's not designed to determine whether people actually *like* the proposal; that's what formal review is for.  In this case, I don't see much room for variation in the basic content: we have to flip the default rule, we have to provide some way to declare a closure as escaping, that way pretty much has to be a parameter attribute, the obvious spelling for that attribute is @escaping, etc.  So if you're happy with the content of the proposal, just send the PR and we'll schedule some time to talk about it.  That time will obviously not be WWDC week. :)

John.

> 
> On Wed, Jun 8, 2016 at 1:17 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
> > On Jun 7, 2016, at 7:25 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <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/e24e58d0/attachment.html>