> Le 15 mai 2017 à 10:55, John McCall <rjmcc...@apple.com> a écrit : > >> On May 15, 2017, at 3:00 AM, Florent Bruneau via swift-evolution >> <swift-evolution@swift.org> wrote: >> 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). > > Three reasons. > > 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. > > 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. > > The final reason is that, when compilers get conservative, they get very > conservative. For example, we can only tell that the NPCR is being violated > by looking at the function that takes the closures, not the one that creates > 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. > > 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.
Thanks for the details, this really helps understanding the choice you made. I can only +1 the proposal. >> >>> Le 13 mai 2017 à 04:29, Ben Cohen <ben_co...@apple.com> a écrit : >>> >>> Hello Swift community, >>> >>> The review of revisions to SE-0176: Enforce Exclusive Access to Memory >>> begins now and runs through May 17, 2017. >>> >>> 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. >>> The proposal is available here: >>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md >>> >>> Since this is a review of revisions only, you may find these two relevant >>> commits easier: >>> https://github.com/apple/swift-evolution/commit/d61c07df2f02bee6c00528e73fbe33738288179a >>> https://github.com/apple/swift-evolution/commit/5205a61f9cdca918d896269521bf89cb11e4aa12 >>> >>> 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. When replying, please try to keep the proposal link at the top of >>> the message: >>> >>> Proposal link: >>> >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md >>> >>> >>> Reply text >>> >>> Other replies >>> What goes into a review? >>> >>> 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: >>> >>> • 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, >>> >>> _______________________________________________ >>> swift-evolution-announce mailing list >>> swift-evolution-annou...@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >> >> -- >> Florent Bruneau >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > -- Florent Bruneau _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
