> • What is your evaluation of the proposal? +1. However, it's unclear to me what the dynamic enforcement will look like: will it trap, emit a warning, be catchable in a debugger, ... More details on the developer-facing interface of the dynamic enforcement would be nice.
> • Is the problem being addressed significant enough to warrant a change to > Swift? The problem is significant, however I can see two significant downsides. The first is the source-breaking nature of the proposal. Breaking source is a problem by itself, but here I'm afraid the errors reporting won't be easily understandable, because "exclusivity" is kind of an advanced feature that won't be easily grasped by developers. My second concern is the performance of the dynamic enforcement. How confident are you that the performance hit of the enforcement will not nullify the gain made by the enabling of more compile-time optimisations? > • Does this proposal fit well with the feel and direction of Swift? Yes. > • 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? Full read. BTW, there is a typo in the "Eliminating non-instantaneous accesses?" section, _Int_appendABunchOfStuff => _Array_appendABunchOfStuff > More information about the Swift evolution process is available at: > > https://github.com/apple/swift-evolution/blob/master/process.md > > > Thanks, > Ben Cohen > Review Manager > > _______________________________________________ > 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
