> * What is your evaluation of the proposal? I’m strongly in favor - improvements on retain cycle issues are a huge win, and escaping as the default better fits the visual layout of the code and forces the developer to think more for the case that’s more conceptually complicated instead of the simple one. The way I read it also suggests that the compiler will be able to give better warnings with nonescaping as the default, and better warnings are rarely a bad thing :). I also like the normalization of the otherwise somewhat awkward and redundant @autoclosure(escaping) syntax - with nonescaping as the default, this is no longer a place where there’s a disconnect between closure behaviors in different contexts.
> * Is the problem being addressed significant enough to warrant a change > to Swift? Definitely; retain cycles are bad enough without making them more painful than they need to be, matching the code’s behavior to its appearance is a net win for ease of use, and the removal of the @autoclosure(escaping) syntax cleans up a place where the language often looks as if it’s deliberately being pedantic in a context where the intent is obvious. > * Does this proposal fit well with the feel and direction of Swift? I couldn’t imagine a better fit - an improvement to syntax, intent, consistency, and behavior all at once; being able to make such improvements is one of the fundamental essences of Swift (at least as I understand it :). > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? I haven’t used any languages which have a similar feature, unless you count Objective-C and its lack of a "nonescaping" syntax (or concept) for blocks (I imagine Clang has code to optimize them when it does detect them, but it definitely wasn't part of the blocks spec last time I read it.) Speaking from that experience and what I’ve done with closures in Swift, I definitely like being able to declare explicitly that my closure doesn’t escape; it clarifies my intent without needing extra text in my headerdocs explaining the block’s semantics. I like it even better with nonescaping as the default - consumers of my API (including myself) don’t have to think nearly as hard about retain cycles in a surprising number of cases (I obviously don’t do much Objective-C bridging ^^; ) > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? I gave it a moderate amount of attention; I haven’t done deep research or refreshed my memory of the semantics further than a quick skim, but I don’t think there are many corner cases that need consideration for this proposal (which is another reason I like it and the way proposals in Swift are done in general). (Also, I generally trust my memory for semantics I was working with successfully an hour ago :) -- Gwynne Raskind _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
