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