DIP 1006 - Preliminary Review Round 1

[Paolo Invernizzi]

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