> * What is your evaluation of the proposal? +1. It's a positive change. It makes un-annotated code safer, and it moves the annotation to the case where one needs to think about captures as opposed to annotating the case where one doesn't have to think about captures.
> * Is the problem being addressed significant enough to warrant a change to > Swift? Yes. It both helps in the un-annotated cases and it adds explicit annotation for escaping closures which serve as a documentation that one need to think about how variables are captured when invoking these functions/methods. > * Does this proposal fit well with the feel and direction of Swift? Yes. It's goes with the safer of the two choices by default. I also imagine that it might be ever so slightly more performant I these cases. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? I've not used another language that explicitly makes a distinction between escaping and non-escaping. Objective-C blocks always capture everything, which has led to a common "weakify/strongify dance" in most cases, even in cases where there wasn't a cycle. > * How much effort did you put into your review? A glance, a quick reading, > or an in-depth study? Read the proposal, skimmed thought the discussion, and a little experimentation with the current syntax. - David > On 22 Jun 2016, at 07:03, Chris Lattner via swift-evolution > <[email protected]> wrote: > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
