On 9/1/18 6:29 AM, Shachar Shemesh wrote:
On 31/08/18 23:22, Steven Schveighoffer wrote:
On 8/31/18 3:50 PM, Walter Bright wrote:
https://news.ycombinator.com/item?id=17880722
Typical comments:
"`assertAndContinue` crashes in dev and logs an error and keeps going
in prod. Each time we want to verify a runtime assumption, we decide
which type of assert to use. We prefer `assertAndContinue` (and I
push for it in code review),"
e.g. D's assert. Well, actually, D doesn't log an error in production.
I think it's the music of the thing rather than the thing itself.
Mecca has ASSERT, which is a condition always checked and that always
crashes the program if it fails, and DBG_ASSERT, which, like D's built
in assert, is skipped in release mode (essentially, an assert where you
can log what went wrong without using the GC needing format).
When you compare this to what Walter was quoting, you get the same end
result, but a vastly different intention. It's one thing to say "this
ASSERT is cheap enough to be tested in production, while this DBG_ASSERT
one is optimized out". It's another to say "well, in production we want
to keep going no matter what, so we'll just ignore the asserts".
Which is exactly what Phobos and Druntime do (ignore asserts in
production). I'm not sure how the intention makes any difference.
The obvious position of D is that asserts and bounds checks shouldn't be
used in production -- that is how we ship our libraries. It is what the
"-release" switch does. How else could it be interpreted?
-Steve
