assert semantic change proposal

[eles via Digitalmars-d]

On Wednesday, 6 August 2014 at 01:39:25 UTC, Mike Parker wrote:
> On 8/6/2014 8:18 AM, David Bregman wrote:
>

>
> You keep going on the premise that your definition is the 
> intended definition. I completely disagree. My understanding of 
> assert has always been as Walter has described it.

I did not use to think the same, but once Walter stated his 
vision of assert(), it was like a kind of revelation to me: why 
the optimizer won't make use of such obvious information like 
assert() provides just like asimple:

if(x<5) {
       // you can safely optimize this code knowing (*assuming*) 
that always x<5
}

But, what started to bother me lately and, I think, is the root 
of the problem: to have programmer code disabled by a compiler 
flag. I do not speak about boundschecking, where the code is 
never explicitely written by the programmer, but of real 
programmer code.

Until now, versioning (or, in C/C++, the #ifdef) was the sole 
acceptable way to disable programmer code. The C assert slipped 
through as being based on a #ifdef or #if (I know good compilers 
will also optimize a if(0), but this is just because it happens 
to be obvious).

OTOH, the D assert is no longer based (directly) on versioning, 
so having it disabled by a flag is not easily grasped. This, 
combined with the sudden revelation of the optimizer messing with 
it, produced a shock and this thread illustrates it. People are 
just to used to its secondary meaning from C, that is, besides 
testing conditions: "easily obtain a log of what and where was 
wrong". So, it was an assertion, but also a logging feature 
(albeit a fatal one). People got used with assert() becoming noop 
code in the release mode, just like they would disable the logs 
for release.

The more I think about it, the more I feel like assert would be 
more naturally an annotation or a kind of versioning. Still, I 
cannot come with a clear cut proposition, as my mind is also 
entangled in old habits. One one hand, it feels natural as an 
instruction, on the other hand, being disable-able, maybe even 
ignorable (in release builds) and an invalidating point for the 
program logic*, it should belong somewhere else.

*I think this is important: is not only a tested condition that 
is then handled, but a tested condition exposing a "does not work 
as intended". It looks more like a kind of "this code should be 
unreachable".