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?


Reply via email to