[swift-evolution] [Review] SE-0103: Make non-escaping closures the default
Diego Sánchez
diego.sanchezr at gmail.com
Thu Jun 23 16:06:55 CDT 2016
** What is your evaluation of the proposal?*
-1
I find myself using 3 types of closures:
- Algorithm-like (filter, map etc.). non-escaping
- Completion closures: asynchronous operations: network requests, many
cocoa APIs, background image processing. escaping
- Data/dependency providers: userProvider(forId id: String) -> User.
escaping (ok, can be non-escaping sometimes too)
In the codebases I'm working with, escaping closures predominate clearly;
and most of the non-escaping ones refer to usages of the standard library.
Another point comes when changing things. Consider the following code:
func doSomething(closure: () -> Void) {
self.doSomething2(closure)
}
func doSomething2(closure: () -> Void) {
self.doSomething3(closure)
}
func doSomething3(closure: () -> Void) {
closure()
}
If non-escaping is the default, and for some reason doSomething3's closure
needs to change to escaping, then I would have to change all the callers as
escaping.
To sump up, I see @noescape as something to opt-in for performance reasons
(or better static analysis as it was mentioned during the initial
discussion) but I don't think it's a good default.
** Is the problem being addressed significant enough to warrant a change to
Swift?*
I don't think there's a problem that needs to be fixed.
** Does this proposal fit well with the feel and direction of Swift?*
Not really. I think escaping is a safe good default that works for all
cases.
** If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?*
NA
** How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?*
Followed the discussion and read the proposal carefully.
2016-06-22 6:03 GMT+01:00 Chris Lattner via swift-evolution <
swift-evolution at swift.org>:
> Hello Swift community,
>
> The review of "SE-0103: Make non-escaping closures the default" begins now
> and runs through June 27. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160623/c1d5b6cb/attachment.html>
More information about the swift-evolution
mailing list