On Wednesday, 7 March 2018 at 09:11:10 UTC, Jonathan M Davis wrote:

So, the request is to just leave assert active as a default in @safe code, like the bounds checks?

No. I'm saying that no optimizations should be enabled which introduce potential memory corruption. Assertions should have zero impact on whether code is @safe or not unless the code in the condition or which is generating the message for the assertion is @system, and it's no more reasonable to assume that an assertion is going to pass than it is to assume that bounds checking won't fail. Regardless, the key thing here is that @safe code should be guaranteed to be @safe so long as @trusted code is vetted properly. It should _never_ be possible for the compiler to introduce memory safety issues into @safe code.

So, the reasoning is that UB should not lead to memory corruption, right?

The reasoning is that no @safe code should ever have memory corruptions in it unless it calls @trusted code that was incorrectly vetted by the programmer. The compiler is supposed to guarantee that @safe code is @safe just like it's supposed to guarantee that a const variable isn't mutated or that a pure function doesn't access mutable, global variables. And as such, introducing anything into @safe code which could be memory unsafe is a violation of the compiler's responsibility.

Jonathan, I understand your reasoning, but it's not what I'm asking: are we asking for UB that do not lead to memory corruption?


Reply via email to