assert semantic change proposal

Sun Aug 3 12:47:26 PDT 2014

I am creating this thread because I believe the other ones [1,6] 
have gotten too bogged down in minutiae and the big picture has 
gotten lost.

Walter has proposed a change to D's assert function as follows 
[1]:
"The compiler can make use of assert expressions to improve 
optimization, even in -release mode."

I would like to raise a series of questions, comments, and 
potential objections to this proposal which I hope will help 
clarify the big picture.

1. Who and Why? What is the impetus behind this proposal? What is 
the case for it? Walter made strong statements such as "there is 
inexorable pressure for this", and "this will happen", and I am 
wondering where this is coming from. Is it just Walter? If not, 
who or what is pushing this idea? (the 'yea' side, referred to 
below)

2. Semantic change.
The proposal changes the meaning of assert(), which will result 
in breaking existing code. Regardless of philosophizing about 
whether or not the code was "already broken" according to some 
definition of assert, the fact is that shipping programs that 
worked perfectly well before may no longer work after this change.
Q2a. In other areas, code breakage has recently been anathema. 
Why is this case different?
Q2b. Has any attempt been made to estimate the impact of this 
change on existing code? Has code breakage been considered in 
making this proposal?
2c. I note that the proposal also breaks with (at least) one of 
D's stated "Major Design Goals".[2] ("Where D code looks the same 
as C code, have it either behave the same or issue an error.")

3. Undefined behavior.
The purpose of the proposal is to improve code generation, and 
this is accomplished by allowing the compiler to generate code 
with arbitrary (undefined) behavior in the case that the 
assertion does not hold. Undefined behavior is well known to be a 
source of severe problems, such as security exploits[3,4], and 
so-called "heisenbugs"[5].
3a. An alternate statement of the proposal is literally "in 
release mode, assert expressions introduce undefined behavior 
into your code in if the expression is false".
3b. Since assert is such a widely used feature (with the original 
semantics, "more asserts never hurt"), the proposal will inject a 
massive amount of undefined behavior into existing code bases, 
greatly increasing the probability of experiencing problems 
related to undefined behavior.
Q3c. Have the implications of so much additional undefined 
behavior been sufficiently considered and weighed with the 
performance benefits of the proposal?
Q3d. How can the addition of large amounts of undefined behavior 
be reconciled with D's Major Design Goals #2,3,5,15,17? [2]?
3f. I note that it has been demonstrated in the other threads 
that the proposal as it stands can even break the memory safety 
guarantee of @safe code.

4. Performance.
Q4a. What level of performance increases are expected of this 
proposal, for a representative sample of D programs?
Q4b. Is there any threshold level of expected performance 
required to justify this proposal? For example, if a study 
determined that the average program could expect a speedup of 
0.01% or less, would that still be considered a good tradeoff 
against the negatives?
Q4c. Have any works or studies, empirical or otherwise, been done 
to estimate the expected performance benefit? Is there any 
evidence at all for a speedup sufficient to justify this proposal?
Q4d. When evaluating the potential negative effects of the 
proposal on their codebase, D users may decide it is now too 
risky to compile with -release. (Even if their own code has been 
constructed with the new assert semantics in mind, the libraries 
they use might not). Thus the effect of the proposal would 
actually be to decrease the performance of their program instead 
of increase it. Has this been considered in the evaluation of 
tradeoffs?

5. High level goals
The feedback so far demonstrates that the proposal is 
controversial at least. While I do not endorse democratic or 
design-by-committee approaches to language design, I do think it 
is relevant if a large subset of users have issues with a 
proposal. Note that this is not bikeshedding, I believe it has 
now been sufficiently demonstrated there are real concerns about 
real negative effects of the proposal.
5a. Is this proposal the best way to go or is there an 
alternative that would achieve the same goals while satisfying 
both sides?
5b. Has the 'yea' side been sufficiently involved in this 
discussion? Are they aware of the tradeoffs? Mostly what I've 
seen is Walter defending the yea side from the perspective that 
the decision has already been made. Maybe if the yea side was 
consulted, they might easily agree to an alternative way of 
achieving the improved optimization goal, such as creating a new 
function that has the proposed semantics.

References:
[1]: http://forum.dlang.org/thread/lrbpvj$mih$1@digitalmars.com
[2]: http://dlang.org/overview.html
[3]: 
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
[4]: http://blog.regehr.org/archives/213
[5]: http://en.wikipedia.org/wiki/Heisenbug
[6]: 
http://forum.dlang.org/thread/jrxrmcmeksxwlyuitzqp@forum.dlang.org