DIP 1006 - Preliminary Review Round 1

[Paolo Invernizzi]

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