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?
/Paolo
