DIP 1006 - Preliminary Review Round 1

[Paolo Invernizzi]

On Tuesday, 6 March 2018 at 23:50:20 UTC, Timon Gehr wrote:
> On 06.03.2018 10:02, Walter Bright wrote:
>> On 3/6/2018 12:45 AM, Timon Gehr wrote:
>>> Anyway, "do not use assert" is not the solution, as I have 
>>> explained many times now.
>> 
>> My interpretation is you want D assert to behave like C assert.
>
> This interpretation is wrong. I, as well as other people, want 
> a compiler option to make the compiler ignore D asserts and 
> contracts. Not more, not less.

Is it an option having the compiler not to remove the asserts 
from @safe code, like bounds check?

Just to understand, otherwise, if the assert is removed and it 
does not hold, you are in UB, so the request is to guarantee 
memory safety in a UB state, right?

The point I don't grasp is why keep running in UB in @safe is 
acceptable, while memory corruption not.

>> Creating library asserts is why D has special support for 
>> __FILE__ and __LINE__ like C does, and for the same reasons.
>
> What I want is special support for sane built-in assert 
> semantics using a compiler flag.

and that's a reasonable request, that, IMHO, does not hurts 
anybody....

> That does not mean that there cannot _also_ be a flag to 
> unleash the nasal demons upon unworthy programmers who were 
> stupid enough to collaborate with someone who imported an 
> external library that was written by somebody who had a bad day 
> one time and left in a wrong assertion.

That's a process management problem, I think.
Debug version of external libraries can be requested, and the 
author can be reported about  the bad-day wrong assert. I know, 
if I can catch it...

> Again: There is no reason why we need to force one behavior 
> over the other. This should be configurable.

I'm all in for having the maximum flexibility in configuration, 
but I would stick with Walter as keeping its idea as the default.

/Paolo