Small @nogc experience report

[Shachar Shemesh]

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