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