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.
