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/jrxrmcmeksxwlyuit...@forum.dlang.org
