<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On May 15, 2017, at 3:00 AM, Florent Bruneau via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="">I may simply have missed something, but I'm not sure to understand why the proposal adds user-facing restrictions instead of using a fallback from static to dynamic enforcement in case of violation of the NRR/NPCR rules (maybe with an additional warning).<br class=""></div></div></blockquote><div><br class=""></div>Three reasons.<br class=""><div><br class=""></div>The first is that it's much simpler for both users and the compiler if there is a bright-line rule guaranteeing that static enforcement will be used. A programmer trying to understand "why is this slower" or "why is this problem only checked at runtime" should not have to understand the language implementation well enough to examine their code and e.g. deduce that the problems is that they made an un-inlineable call during an access within a closure and the compiler couldn't prove that that didn't lead to a re-entrant access and so it fell back to dynamic enforcement. Paring back dynamic enforcement to the same cases where we need to allocate variables on the heap is far more straightforward to explain and understand.</div><div><br class=""></div><div>The second is closely related, which is that it preserves the ability to have a subset of the language which doesn't need dynamic allocation or enforcement. This sort of performance and semantic guarantee is important in a number of situations, from audio programming to low-level systems work. You could imagine having a special scope, or even a compiler flag, that mandates staying within that subset. But you wouldn't want that flag to change the dynamic behavior of the program or rely for correctness on an assumption that the entire program, libraries included, are compiled with the flag. And that ties in with the next point.</div><div><br class=""></div><div>The final reason is that, when compilers get conservative, they get <i class="">very</i> conservative. For example, we can only tell that the NPCR is being violated by looking at the function that <i class="">takes</i> the closures, not the one that <i class="">creates</i> them; but it's the latter function which decides what enforcement to use for its captured variables. Statically detecting NPCR violations, therefore, basically requires the ability to inline every function to which we passed them — we don't actually have to do the inlining, but we do have to be able to see their definitions, which in many cases is not possible. And most of the heuristics you might imagine we could use to statically prove that a closure can't be recursively invoked aren't actually valid. So conservatively falling back on dynamic enforcement in closures really means doing it pervasively.</div><div><br class=""></div><div>When you take those reasons and balance them against the patterns that are being restricted here — and really, they're still legal, you just have to mark one of the closures as escaping —it's not really a difficult choice.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">Le 13 mai 2017 à 04:29, Ben Cohen <<a href="mailto:ben_cohen@apple.com" class="">ben_cohen@apple.com</a>> a écrit :<br class=""><br class="">Hello Swift community,<br class=""><br class="">The review of revisions to SE-0176: Enforce Exclusive Access to Memory begins now and runs through May 17, 2017.<br class=""><br class="">Most of this proposal was previously accepted. An implementation issue has been discovered with the use of dynamic enforcement on inout parameters. The proposal implementors suggest adopting a stronger rule governing the use of non-escaping closures which will also allow Swift to make firm guarantees about the use of static enforcement when a variable does not escape. The core team tentatively supports this new rule but believes it is a substantial enough revision that it requires a separate review period.<br class="">The proposal is available here: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md</a><br class=""><br class="">Since this is a review of revisions only, you may find these two relevant commits easier:<br class=""><a href="https://github.com/apple/swift-evolution/commit/d61c07df2f02bee6c00528e73fbe33738288179a" class="">https://github.com/apple/swift-evolution/commit/d61c07df2f02bee6c00528e73fbe33738288179a</a><br class="">https://github.com/apple/swift-evolution/commit/5205a61f9cdca918d896269521bf89cb11e4aa12<br class=""><br class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class="">or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:<br class=""><br class="">Proposal link:<br class=""><br class=""><br class="">https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md<br class=""><br class=""><br class="">Reply text<br class=""><br class="">Other replies<br class="">What goes into a review?<br class=""><br class="">The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• What is your evaluation of the proposal?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Is the problem being addressed significant enough to warrant a change to Swift?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Does this proposal fit well with the feel and direction of Swift?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class="">More information about the Swift evolution process is available at:<br class=""><br class="">https://github.com/apple/swift-evolution/blob/master/process.md<br class=""><br class="">Thank you,<br class=""><br class="">_______________________________________________<br class="">swift-evolution-announce mailing list<br class="">swift-evolution-announce@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution-announce<br class=""></blockquote><br class="">-- <br class="">Florent Bruneau<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>