> On Jun 9, 2016, at 3:17 PM, Trent Nadeau <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > > On Jun 7, 2016, at 7:25 PM, Brent Royal-Gordon via swift-evolution > > <[email protected] <mailto:[email protected]>> 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 > > [email protected] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > > -- > Trent Nadeau
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
