assert semantic change proposal

[David Bregman via Digitalmars-d]

On Sunday, 3 August 2014 at 21:57:08 UTC, John Carter wrote:

> One "near term" implication is to permit deeper static checking 
> of the code.
> Both in terms of "Well, actually there is a code path in which 
> the assert expression could be false, flag it with a warning" 
> and in terms of "There is a code path which is unused / 
> incorrect / erroneous is the assert expression is true", flag 
> as an error/warning.
>
> Furthermore, in the presence of the deeper compile time 
> function evaluation, I suspect we will get deeper and even more 
> suprising consequences from this decision.
>
> Suddenly we have, at compile time, an expression we know to be 
> true, always, at run time. Thus where possible, the compiler 
> can infer as much as it can from this.
>
> The implications of that will be very very interesting and far 
> reaching.

I totally agree, static analysis tools should consider 
information contained in asserts. In the case of C/C++, I believe 
many of the analysis tools already do this. That doesn't mean 
it's a good idea for this information to be used for optimization 
though, for reasons explained in the OP.

> As I said, this choice will have very far reaching and 
> unforeseen and unforeseeable consequences.... but that's OK, 
> since it is fundamentally the correct choice, those 
> consequences will be correct too.

This is mystical sounding gibberish. If the consequences are 
unforseen and unforseeable, then by definition you cannot forsee 
that they are correct.