On Monday, March 05, 2018 02:30:12 Walter Bright via Digitalmars-d wrote:
> The idea behind removal of the runtime checks is as a performance
> optimization done on a debugged program. It's like turning on or off
> array bounds checking. Many leave asserts and array bounds checking on
> even in released code to ensure memory safety.
> At a minimum, turning it off and on will illuminate just what the checks
> are costing you.
> It's at the option of the programmer.

Except that disabling array bounds checking negates the guarantees of @safe,
and you have to go to the extra effort of supplying a compiler flag to tell
the compiler that you don't care about the compiler guaranteeing @safe.

And your suggesting that with assertions, @safe's guarantees can be removed.
You never catch everything when debugging or running your program prior to
releasing it. Assertions can help considerably in catching problems, but
there is zero guarantee that that they've caught all of the problems.
They're disabled in release mode on the theory that the program has been
tested enough that that assertions are unlikely to fail, but they could
still have failed if they remained.

It's one thing to remove the assertions and let your program behave badly as
a result whenever you didn't catch all of the problems. It's quite another
to have the compiler make your code @safe code @system on the assumption
that the assertion would have passed. Personally, I don't mind if the
compiler is able to make optimization decisions based on assertions - the
code is buggy anyway if the assertion would have failed - but I very much
mind if those optimizations introduce behavior that could violate @safe.
Because then, instead of just having a bug, you have memory corruption
problem, which could be really hard to detect and track down, and it would
be essentially invisible, because most programmers who understand @safe and
@trusted, would assume that they needed to check the @system code and
@trusted code for the problem, when it could now be sitting in @safe code
just because one of the developers added an assertion to help catch a bug
during testing. If assertions make it possible for @safe code to actually be
@system, that seems like a serious bug to me.

IIRC, Andrei made a huge deal with you several years ago about how array
bounds checking needed to be kept in @safe code or @safe meant nothing. I
don't see how this situation is any different. @safe code needs to
guaranteed to be @safe so long as @trusted is used correctly, otherwise,
@safe is arguably meaningless - certainly, it then doesn't restrict the code
that you have to look through for memory safety problems, and that's one of
the main purposes of @safe.

If you want to introduce a compiler flag like -boundscheck=off that makes it
so that compiling out assertions can introduce @system behavior, then fine.
But removing assertions with -release and removing @safety guarantees are
two completely separate issues. I sure don't want assertions in my
production builds; I'd be forced to use them a lot less if they were going
to be in my production builds. But I also don't want to introduce @safety
issues into my production builds by using assertions.

You keep talking about how important @safety is to D and how much better it
makes it than C, and then you go and talk about invisibly removing @safety
guarantees with common, built-in features like assertions. If assertions
removed @safety guaranatees, I would be forced to never use them in my code,
which IMHO is ridiculous and is certainly going to make my code worse. And
IMHO, suggesting that someone should then use a user-defined assertion isn't
a good solution either, because then the built-in default that everyone is
going to use unless someone more knowledgable tells them not to is an
@safety problem.

If you want to be able to optimize based on assertions then fine, but
please, please, please do not allow the compiler to introduce @safety
problems when adding optimizations - preferably not even in @system code,
because realistically, almost no one is going to have a clue what @safety
problems could be introduced by an optimization based on an assertion,
making it impossible for the programmer to verify that @system code can be
marked @trusted. And most programmers won't know that assertions could even
introduce optimizations that weren't memory safe.

I honestly don't see how we can claim that @safe code is guaranteed to be
memory safe if assertions - or any other D feature other than the programmer
using @trusted incorrectly - could introduce anything that is not guaranteed
to be memory safe.

- Jonathan M Davis

Reply via email to