> On May 3, 2017, at 3:56 PM, Florent Bruneau <florent.brun...@intersec.com> > wrote: > > >> 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.
That's generally a very important concern. I do think it's less likely to apply here because beginners are quite a bit less likely to be experimenting with oddly-nested inout arguments, or inout arguments at all. John. > >>> 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
