> On Dec 19, 2015, at 4:38 PM, Dmitri Gribenko via swift-evolution > <[email protected]> wrote: > > On Sat, Dec 19, 2015 at 12:10 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: >> @noescape is safer because it does not require thinking about lifetime >> issues for captured objects. My hunch was that @noescape (or @autoclosure >> with implies @noescape) is also more common. I had a look through the >> standard library and this is definitely the case there. >> >> What does everyone think about making @noescape the default and introducing >> @escaping (or something similar) to annotate function arguments that do >> escape the call stack? > > @noescape provides additional guarantees and the optimizer can learn > to rely on it in future. Thus, it effectively becomes ABI, and you > can't remove in future versions of the library without breaking the > ABI. I think adding it should be an explicit decision because of > that.
I agree. This is a very significant API restriction that should be opted-into intentionally. It affects subtyping relationships in protocol conformances and overrides as well. A different objection to @noescape-by-default is that it makes closures second citizens by default, which makes teaching and learning higher-order functional programming significantly less awesome. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
