On 19/09/18 22:53, Walter Bright wrote:
On 9/19/2018 10:13 AM, Shachar Shemesh wrote:
assert(condition, string); // string is useless without actual info
about what went wrong.
assert(condition, format(string, arg, arg)); // No good - format is
not @nogc
Another method:
debug
assert(condition, format(string, arg, arg));
else
assert(condition, string);
because @nogc is ignored in debug conditionals, just like purity is
ignored in debug conditionals.
That doesn't cut it on so many levels...
First of all, no four lines solution that requires copy/paste (or worse,
retyping) as a standard will actually get employed by programmers. The
disincentive is too high.
If we overcome this problem, we're still left with the fact that in all
of the important runs the data I need in order to debug an assert
violation is not going to be there when I need it.
Let me put it this way: the Weka code base has over 13,000 asserts.
Every single time an assert triggered on me that either did not have a
message, or had only a message but not data, I needed more data than it
had. It is, unfortunately, not true to say that this only ever happened
in debug builds. In fact, we do release builds with asserts as part of
our CI, so a relatively rare bug has a very high chance of throwing an
assert in non-debug runs.
Writing asserts should be easy, and making them useful in case they
trigger should also be easy. What's more, soft mandating writing asserts
with assert messages and parameters all but eliminates the common
anti-pattern used by many novices of asserting that the compiler does
what it's supposed to, e.g:
if( a>13 )
return;
assert(a<13);
Shachar
