assert semantic change proposal

Sun Aug 3 13:05:21 PDT 2014

Thanks for the summary. I apologize for the uninformed question, 
but is it possible to explain how the change wrt assert will 
break existing code? Those details are probably buried in the 
extensive threads you've referenced. I ask because my 
understanding of assert has always been that you should use it to 
test your programs but not rely on it at runtime.

On Sunday, 3 August 2014 at 19:47:27 UTC, David Bregman wrote:
> 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