DIP 1006 - Preliminary Review Round 1

[Jonathan M Davis]

On Wednesday, March 07, 2018 13:24:19 Paolo Invernizzi via Digitalmars-d 
wrote:
> > 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?

That would make assertions a lot worse to use, because then they would be in
production code slowing it down. Also, as it stands, -release is not
supposed to violate @safe. To do that, you have to use -boundscheck=off to
turn off bounsd checking. That was a very purposeful design decision,
because we did not want -release to violate @safe, and if the compiler is
allowed to add optimizations which are unsafe based on assertions, then that
completely destroys the ability to have @safe code with -release. And if we
were going to do that, why did we leave array bounds checking on with
-release?

Assertions are to help debug code, and most people disable them in
production with zero expectation that that's going to result in their @safe
code suddenly becoming unsafe.

It's a huge change if -release makes code unsafe, and IMHO, doing so would
make assertions an immediate code smell and that assertions should then
never be used except by folks who are willing to leave them in all the time.
I don't see how it can be argued that allowing assertions to introduce
unsafe behavior into @safe code is not in complete violation of what @safe
is supposed to do and guarantee.

It's already bad enough that we talk about how memory safe D code is when
@safe isn't the default, but to then completely bypass @safe like this seems
unconscionable to me. That would be like deciding that we're now going to
introduce cast_cast and mutable into the language and allow const's
guarantees to be violated whenever the programmer feels like it. @safe needs
to actually be guaranteed to be @safe or it's worthless.

- Jonathan M Davis