Hi, 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).
> 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
