> On 3 May 2017, at 22:06, John McCall via swift-evolution > <[email protected]> wrote: > >> >> On May 3, 2017, at 3:56 PM, Florent Bruneau <[email protected]> >> wrote: >> >> >>> Le 3 mai 2017 à 17:23, John McCall <[email protected]> a écrit : >>> >>>> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution >>>> <[email protected]> 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.
I think it would be fairly important to get a nice and helpful error message if the exclusivity is violated, for developers of all skill levels to understand what’s happening and to know what to do about it. I don’t know if it’s something that’s worth pointing out specifically or not. / David > >> >>>> 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 >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >>>> >>>> -- >>>> Florent Bruneau >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> -- >> Florent Bruneau >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
