On Monday, 28 July 2014 at 13:50:29 UTC, Daniel Murphy wrote:
Yes, writing code wrong can result in the wrong thing
happening. A non-release build will always retain the asserts.
No, writing wrong code is one thing.
Having a single typo in a constraint-test cause memory unsafety
undetected is a disaster. And many such typos _will_ go
undetected.
Let's say you want to test "divisor >= 0", but end up with
"divisor != 0" => division_by_zero failure even if the code is
correct.
Adding assert() should increase quality, not decrease it. Adding
asserts will increase the probability of wrong constraints
entering the codebase. That means with the regime indicated here
you should write as few assert() statements as possible.
Assert() are useful debugging tools, but not a codegen
feature. A good debugger could allow you to turn them on/off
or let you continue after hitting one. That's useful.
If this is what you want you shouldn't be using assert. This
is not what assert means in D.
Where in the spec does it say that assert is a tool for
specifying optimization constraints?
That would be a disaster.
