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