On Wednesday, 6 August 2014 at 00:50:07 UTC, Walter Bright wrote:
On 8/3/2014 4:24 PM, Martin Krejcirik wrote:
Couldn't this new assert behaviour be introduced as a new
optimization
switch ? Say -Oassert ? It would be off by default and would
work both
in debug and release mode.
It could, but every one of these:
1. doubles the time it takes to test dmd, it doesn't take many
of these to render dmd untestable
2. adds confusion to most programmers as to what switch does
what
3. adds complexity, i.e. bugs
If performance is not worth associated complexity, then it
doesn't pull its weight.
4. interactions between optimization switches often exhibits
emergent behavior - i.e. extremely hard to test for
Why do you think the emergent behavior is caused by interactions
between switches, you think optimizations themselves don't
interact? You said, it's factorial, is it a number of
permutations of switches or a number of permutations of
optimizations? Switches should not be sensitive to permutations.
On Wednesday, 6 August 2014 at 08:25:38 UTC, Walter Bright wrote:
1. it's long with an unappealing hackish look
It's an established practice in D that unsafe features should
look unappealing. Example: __gshared.
3. users will be faced with two kinds of asserts, with a subtle
difference that is hard to explain, hard to remember which is
which, and will most likely use inappropriately
Andrei already proposed `debug assert` - a safe flavor of
(dangerous by default) assert. So two kinds of assert are
inevitable and should be documented, because user should be
informed about dangerous optimizations. But frankly "compiler
will break your code" is not a subtle difference and can be
easily explained in just 5 words.
And BTW why safe behavior must be invoked with an extra syntax?
That goes against best D practices and hence surprising,
confusing and counterintuitive.
I'll sum up with the old saw that any programming problem can
be solved with another level of indirection. I submit a
corollary that any language issue can be solved by adding
another keyword or compiler flag. The (much) harder thing is to
solve a problem with an elegant solution that does not involve
new keywords/flags, and fits in naturally.
So what is this elegant solution? To break code silently in the
worst possible way and selectively and exactly at the most
critical points?
Another downside of assert being dangerous - you can't add it to
code freely. Every assert can order the compiler to break the
code, adding an assert becomes a difficult task, because the
asserted expression (being assumed) begins to require a thorough
future-proof environment-independent proof, which is very hard to
come by: it needs to be an actual proof than just a guess,
because the tradeoff is to be literally punished by death.
Unittests don't provide such proof.
