DIP 1006 - Preliminary Review Round 1

[Jonathan M Davis]

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. If UB must be disallowed to
avoid violating @safe, then it must be disallowed. 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. 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. 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.

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. 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.

- Jonathan M Davis