> On Jan 2, 2016, at 2:57 AM, Arnold <aschwaigho...@apple.com> wrote: > > 'assert' evaluates the condition and aborts only in Odebug builds. > > 'precondition' evaluates the condition and aborts also in optimized -0 builds. > > As far as I remember the decision was made to give it this semantics to > mimic C's assert() function. > > If an abort is desired in optimized builds one should use 'precondition’.
Thanks, Arnold, but this doesn’t address the key question: in -O builds, does the optimizer make optimizations based on the assumption that asserts would not fire if they were enabled? > > Sent from my iPhone > >> On Jan 2, 2016, at 8:27 AM, Dave Abrahams <dabrah...@apple.com> wrote: >> >> >>>> On Jan 1, 2016, at 11:25 PM, Chris Lattner <clatt...@apple.com> wrote: >>>> >>>> On Dec 31, 2015, at 1:56 PM, Dave Abrahams <dabrah...@apple.com> wrote: >>>>>> 2) Adding asserts to code should not make the code more dangerous >>>>>> whatever the build. Assuming the truth of the assert may lead to runtime >>>>>> safety checks being skipped and undefined behaviour when a no-op would >>>>>> be a safe behaviour. >>>>> >>>>> This only affects code built with -Ounchecked, which is definitely not a >>>>> safe mode to build your code. The intention of this mode is that you can >>>>> use it to get a performance boost, if you believe your code to be >>>>> sufficiently tested. This mode, which isn’t the default in any way, >>>>> intentionally takes the guard rails off to get better performance. >>>>> >>>>> If you don’t like that model, don’t use this mode. >>>> >>>> Let’s just consider -O; I think I understand Joseph’s objection here, and >>>> it seems valid. >>> >>> Ah, good point. >>> >>>> Normally in -O, we say that if you stay in the “safe subset” of Swift >>>> code, you never get undefined behavior, even if there’s a bug in your >>>> code. You might get *unpredictable* behavior of course, but presumably >>>> guaranteeing no undefined behavior rules out large classes of problems, >>>> including many security holes. Now suppose you decide to be responsible >>>> and add some asserts to help you catch bugs during development. Hopefully >>>> they help you catch all the bugs, but what if they don’t? All of a >>>> sudden, if you still have a bug when you ship, you now have undefined >>>> behavior. As much as I’m a fan of assertions having optimization >>>> benefits, It seems a little perverse that using them could make shipping >>>> code less secure. >>> >>> Yes, I agree. -O should not imply undefined behavior in the case of an >>> assert() predicate being dynamically false. >>> >>> It sounds like we just need a documentation update here? >> >> I’m pretty sure the documentation reflects assumptions that the optimizer is >> already taking advantage of, but the performance team knows for sure. >> >> -Dave >> -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
