[swift-evolution] [Review] SE-0103: Make non-escaping closures the default

[Brent Royal-Gordon]

> 	* What is your evaluation of the proposal?

I support it; if escaping and nonescaping are about equally common, but users would never discover a @nonescaping on their own, I think it makes sense to have @escaping instead.

However, I'm concerned about migration. Rather than saying that all currently escaping closures will be marked with @escaping, the proposal says:

> Existing code using the @noescape attribute will need to be migrated to remove the attribute since it will be the default. In addition, the compiler will need to detect escaping closures that are not marked with @escaping and create an error with a fixit to add the required attribute.

If I'm reading this correctly, it's saying that the migrator will convert *all* closures into nonescaping closures and then let compiler errors guide the user to convert those that need to escape. This is going to add to the burden of migrating code to Swift 3. And the compiler may not catch all mistakes—consider, for instance, a framework which defines a public delegate protocol with a method that takes a completion or reply closure. That parameter probably ought to be @escaping, but if it's not, nothing in the module itself will break.

I think it would be better if the migrator added @escaping to all currently-non- at noescape closures, thus preserving current semantics. The cost of doing so—forgoing a speed improvement—is just not that large. And I can just imagine the tableflip I would do if I were assigned to migrate, say, Alamofire to Swift 3 and it forced me to manually annotate *every* closure parameter in the entire library.

Failing that, I would consider at least doing so on public methods of protocols and nonfinal classes, where the concerns are most acute. I would also like to see the migrator automatically add @escaping to closure parameters it heuristically determines are probably escaping—at the very least, `completion` and `completionHandler` trailing closures.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

> 	* Does this proposal fit well with the feel and direction of Swift?

Yes. @noescape was just weird.

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

None I can think of, unless Objective-C is somehow doing this behind my back.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

-- 
Brent Royal-Gordon
Architechies