assert semantic change proposal

[Kagamin via Digitalmars-d]

On Wednesday, 6 August 2014 at 00:50:07 UTC, Walter Bright wrote:
> On 8/3/2014 4:24 PM, Martin Krejcirik wrote:
>> Couldn't this new assert behaviour be introduced as a new 
>> optimization
>> switch ? Say -Oassert ? It would be off by default and would 
>> work both
>> in debug and release mode.
>
> It could, but every one of these:
>
> 1. doubles the time it takes to test dmd, it doesn't take many 
> of these to render dmd untestable
>
> 2. adds confusion to most programmers as to what switch does 
> what
>
> 3. adds complexity, i.e. bugs

If performance is not worth associated complexity, then it 
doesn't pull its weight.

> 4. interactions between optimization switches often exhibits 
> emergent behavior - i.e. extremely hard to test for

Why do you think the emergent behavior is caused by interactions 
between switches, you think optimizations themselves don't 
interact? You said, it's factorial, is it a number of 
permutations of switches or a number of permutations of 
optimizations? Switches should not be sensitive to permutations.

On Wednesday, 6 August 2014 at 08:25:38 UTC, Walter Bright wrote:
> 1. it's long with an unappealing hackish look

It's an established practice in D that unsafe features should 
look unappealing. Example: __gshared.

> 3. users will be faced with two kinds of asserts, with a subtle 
> difference that is hard to explain, hard to remember which is 
> which, and will most likely use inappropriately

Andrei already proposed `debug assert` - a safe flavor of 
(dangerous by default) assert. So two kinds of assert are 
inevitable and should be documented, because user should be 
informed about dangerous optimizations. But frankly "compiler 
will break your code" is not a subtle difference and can be 
easily explained in just 5 words.

And BTW why safe behavior must be invoked with an extra syntax? 
That goes against best D practices and hence surprising, 
confusing and counterintuitive.

> I'll sum up with the old saw that any programming problem can 
> be solved with another level of indirection. I submit a 
> corollary that any language issue can be solved by adding 
> another keyword or compiler flag. The (much) harder thing is to 
> solve a problem with an elegant solution that does not involve 
> new keywords/flags, and fits in naturally.

So what is this elegant solution? To break code silently in the 
worst possible way and selectively and exactly at the most 
critical points?

Another downside of assert being dangerous - you can't add it to 
code freely. Every assert can order the compiler to break the 
code, adding an assert becomes a difficult task, because the 
asserted expression (being assumed) begins to require a thorough 
future-proof environment-independent proof, which is very hard to 
come by: it needs to be an actual proof than just a guess, 
because the tradeoff is to be literally punished by death. 
Unittests don't provide such proof.