> On Dec 31, 2015, at 1:56 PM, Dave Abrahams <[email protected]> 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? -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
