DIP 1006 - Preliminary Review Round 1

[Paolo Invernizzi]

On Wednesday, 7 March 2018 at 11:52:05 UTC, Jonathan M Davis 
wrote:
> On Wednesday, March 07, 2018 09:22:40 Paolo Invernizzi via 
> Digitalmars-d wrote:
>> 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?
>
> I'm saying that @safe code must not be violated by the 
> compiler. Beyond that I'm not arguing about UB one way or the 
> other.

And that's clear.

> If UB must be disallowed to avoid violating @safe, then it must 
> be disallowed.

And how to do this, in practise I mean?

> If some form of UB can be allowed, because it's restricted in a 
> manner that it can't violate @safe but may do something else 
> stupid because the assertion would have failed if it weren't 
> compiled out, I don't care.

And that's the original question: are we asking for UB that do 
not lead to memory corruption?

> If an assertion would have failed if it weren't compiled out, 
> then you have a bug regardless, and if the code is buggier 
> because of an optimization, then that's fine with me. You have 
> a bug either way.

Agreed.

> What isn't fine is that that result violate @safe, because that 
> would defeat the entire purpose of @safe and make it far, far 
> more difficult to track down @safety problems.

So, see above, the original question, agreed.

> Right now, since no optimizations like Walter has been talking 
> about are done by the compiler, if you have memory corruption, 
> you know that you only have to look at @system and @trusted 
> code to find it, whereas with the unsafe optimizations that 
> Walter is talking about, it then becomes possible that you're 
> going to have to look through the entire program to find the 
> problem.

Or you can just turn on assertion, right?

If we have corrupted memory in release, there's a bug, somewhere, 
in the logic or in the implementation of the logic.
As you have told, we must audit @system and @trusted, we can 
imagine to use static checkers or some strange beast like that.
But, while doing that, I think that the most common practise is 
keep running the code with assertion on, do you agree?

> And right now, you can be sure that you don't have @safety 
> problems in @safe code if you use @trusted correctly, whereas 
> with what Walter is talking about, simply adding an assertion 
> could add @safety problems to your code.

Nope, not adding an assertion, but having the process in UB state.
And we are back again to the original question.

/Paolo