DIP 1006 - Preliminary Review Round 1

[Timon Gehr]

On 05.03.2018 22:11, Walter Bright wrote:
> On 3/5/2018 11:34 AM, Timon Gehr wrote:
>> On 05.03.2018 11:30, Walter Bright wrote:
>>> The hints will usually not make a significant difference in 
>>> performance anyway.
> 
> Reasonable people will disagree on what is significant or not.
> ...

My point exactly! Hence, compiler flag.

> ...
>>
>> I did not make the code any more wrong by adding the assertion.
>> Why should I get more UB?
> 
> Because you put in an assert that did not hold, and disabled the check.
> ...

(Maybe let's assume it was not me who did it, to stop the whole silly 
"you deserve what you got because you made a mistake" notion.)

Again, my question is not about the _mechanics_ of the status quo. I 
know it very well. It's the rationale that matters.

> 
>> Now we have the following options:
>>
>> - Leave contracts in -- fail performance requirements.
>>
>> - Remove contracts -- fail safety requirements.
>>
>> - Track down all 'assert's, even those in external libraries, and 
>> replace them by a custom home-cooked solution that is incompatible 
>> with everyone else's -- fail maintainability requirements.
>>
>> To me this situation is ridiculous.
> 
> It's completely under the control of the programmer. I know you disagree 
> with that notion.

I don't. I can use a manual patch of the compiler that has the 
additionally required flags and replicate the official packaging effort 
and make everyone who wants to compile my programs use that version. I 
just don't want to, as it seems silly.

It would be a lot better if the standard DMD compiler had the flags. Do 
you disagree that there should be an additional option to ignore 
contracts completely?

> You can even create your own `myassert` to produced 
> your desired semantics.
> ...

That's the third option above. It's not a practical solution. Putting 
the flag into a compiler fork is trivial by comparison.

> 
>> FWIW, this is what all contract systems that I'm aware of do, except 
>> D, and maybe C asserts in certain implementations (if you want to call 
>> that contracts).
> 
> D is better (!).
> 
> (C's asserts are not part of the language, so impart no semantics to the 
> compiler.)
> 

(That's why I said "in certain implementations".)