DIP 1006 - Preliminary Review Round 1

[Timon Gehr]

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.

> C assert 
> and enforce are purely creatures of the library, with semantics defined 
> by their library implementation, and have no effect on the core language.
> ...

That's a meaningless proposition. The current D -release assert behavior 
can be implemented in a library (just trigger UB in the false branch).

> I recommend creating your own library assert, call it 'check' for 
> example, and give it the semantics you wish. You can even have it expand 
> to nothing for release builds.
> ...

Well, awesome. Now I need to make everyone on the project as well as 
external libraries, such as Phobos, use my 'check' function, when the 
contract documentation tells them to use assert and does not even hint 
at the downsides. No, thanks. I'd rather fork the compiler.

But I have explained this (and further reasons) already. I suspect you 
did not read my posts. A few others have. I'll try to keep this one shorter.

> 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. 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.

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