On Tuesday, 6 March 2018 at 20:03:11 UTC, Jonathan M Davis wrote:
On Tuesday, March 06, 2018 18:49:42 Paolo Invernizzi via
Digitalmars-d wrote:
I simply don't understand why enforce or a custom check can't
be used @safe code, if you want that behaviour.
If the program must HALT on this or that, well, what is better
than an explicit piece of unremovable code that do that?
Instead of writing 'assert', one should write 'enforce'.
1. It's quite common for folks to want to add debugging checks
that are compiled out in -release. That's exactly what assert
is for in pretty much every lanugage that has it. It's what
folks expect to use and what your average programmer will use
without thinking about @safety issues at all. It's what
everyone uses right now, and I'm pretty sure that almost
everyone using it has no clue that Walter considers it okay for
assertions to introduce optimizations which are not memory
safe, and if/when he does do so, a lot of D code will suddenly
have @safe code which is not memory safe. Such problems will
hopefully be hit rarely, because hopefully, the code will have
been well-tested, and the assertions will have found all of the
related bugs, but there's every possibility that some bugs will
manage to not be caught, thereby resulting in @safe code being
unsafe. No one is going to be looking to use solutions other
than assertions for what assertions are for unless we start
telling everyone to avoid assertions, because they make @safe
code unsafe. And honestly, if assertions make @safe code
unsafe, I don't see a good argument for using them at all. If I
didn't care about code being @safe, I wouldn't be using @safe.
@safe is supposed to guarantee that the code is memory safe.
Understood. Are asking that UB should not include memory
corruptions?
2. I think that it's fundamentally a terrible idea to allow
built-in language features to violate @safe. Aside from issues
related to @trusted being misused, @safe code should be
guaranteed to be memory safe, and it should be considered a bug
any time that it isn't. That's why @safe exists. No one should
have to be looking at @safe code to track down memory safety
problems. And if they do, then @safe is not doing it's job.
Array bounds checks are left in @safe code for exactly these
reasons.
So, the request is to just leave assert active as a default in
@safe code, like the bounds checks?
I'm all for introducing optimizations that do not violate
@safe, but if we allow @safe code to be unsafe, then why do we
even have it?
So, the reasoning is that UB should not lead to memory
corruption, right?
/P
