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
