> Le 3 mai 2017 à 17:23, John McCall <rjmcc...@apple.com> a écrit : > >> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution >> <swift-evolution@swift.org> wrote: >>> • 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. > > It will trap. That trap will of course be caught in the debugger, and > hopefully the debugger will be able to deliver a nice debugging experience > here. > >>> • 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. > > Our hope is that this will trigger very rarely and that we can make sure that > there's suitable documentation for what it means.
I'm worrying this may trigger more often on beginners' code because beginners will experiment and write incorrect code more often than experimented dev who have learned idiomatic code patterns. >> 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? > > It's a performance trade-off where, unfortunately, the upsides and downsides > will be seen in very different code. Dynamic enforcement will kick in mostly > for code that makes heavy use of mutable class properties, e.g. traditional > Cocoa programming. We expect that the optimization advantages will mostly be > seen in code that makes heavy use of value types, especially copy-on-write > value types like the standard library's data structures. Of course, > traditional Cocoa programming also does use a lot of dictionaries and arrays, > so it's possible that the advantages will offset each other. > > One direction we're exploring for dynamic enforcement is enabling it only in > certain builds by default (e.g. debug configurations). Unlike array bounds > checks and integer overflows, exclusivity violations are generally not > data-dependent: it's usually true that just executing the code in any > configuration will adequately test for dynamic exclusivity violations. You > can get them with races, of course, but the dynamic enforcement mechanisms > we're looking at will probably not detect cross-thread violations anyway. Of > course, you can make a reasonable argument that not enabling dynamic > enforcement checks in production builds would contradict Swift's general > policy of "safe by default", so this is not a certain thing. We would very > much like to hear swift-evolution's thoughts about this. I would go for disabling the dynamic checks in productions. The rational is mostly the little gain compared to the performance overhead. >>> • 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 > > Thank you, this has been fixed. > > John. > >> >>> 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 > -- Florent Bruneau _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
