On Wed, Jun 1, 2016 at 9:11 PM, Chris Lattner via swift-evolution < [email protected]> wrote:
> On Jun 1, 2016, at 9:02 PM, Chris Lattner <[email protected]> wrote: > > 2) For noescape, the core team feels that the right solution is for > closure arguments to *default* to noescape, which means that the attribute > we should really need is @escaping. > > To provide some more details, this approach has the following advantages: > > - Most functional algorithms written in pure Swift will benefit because > they are naturally noescape. The core team feels that this will reduce the > boilerplate involved with writing these algorithms. > > - The compiler has enough logic in it to provide a great QoI experience > when a developer doesn’t think about escaping, and tries to escape a > closure - it can provide a fixit that suggests adding @escaping. > > - Recent changes (to disallow escaping closures to close over an inout > parameter) are pushing the language to prefer noescape closures. noescape > closures have also always been the preferred default, since they eliminate > a class of retain cycle issues. > > - "@autoclosure(escaping)" can be simplified and standardized to > "@autoclosure @escaping” > > > The two primary concerns with taking this direction were that it is would > adversely impact resilience, and that imported Objective-C APIs would be > too annoying to work with, because the compiler would have to be > conservative and assume they are escaping: > > > > On resilience, the concern with this approach is that an API may not > thinking about whether a closure parameter should be escaping or not, and > this behavior makes it possible that someone could write “V1” of an API and > not accidentally promise noescape semantics, but then need it in “V2” of > the same API. > > John McCall pointed out that resilience in the type system is different > than resilience in practice: An API changing to capture a closure and use > it long after it was originally passed is likely to break the clients > regardless of whether the type system captures this as an issue. He argues > (and the argument is strong IMO) that it is *better* for resilient APIs to > default to @noescape, since that forces the author of V2 to think about > whether they are breaking their clients. If they are doing something that > is “logically” noescape in their V2, then they can unsafe bitcast away the > escaping aspect of the closure. This is better than changing the client’s > view of the API in any case. > > > On imported Objective-C API, the core team did a quick study of the Cocoa > APIs and found that most closure/block parameters are escaping in > practice. As such, the core team feels that it isn’t overly burdensome to > ask that imported Objective-C APIs annotate their semantically noescape > block parameters with the clang __attribute__((noescape)) attribute. > This part is what I proposed last year; still waiting on an update: https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md > > > I’m happy to write up this proposal, but won’t have cycles to do so for > several weeks. If someone else wants to take it up, that would be great :-) > > -Chris > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
