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