Unit tests, asserts and contradictions in the spec

[Paul Backus]

On Thursday, 7 February 2019 at 01:04:15 UTC, H. S. Teoh wrote:
> [...]
>
> Of course, one could argue that checkArgs ought to return bool, 
> and the assert moved into the contract itself.  That's probably 
> a reasonable thing to do, but existing code may not follow such 
> a practice.

Having a function call that's UB outside a contract but fine 
inside one seems pretty suspect to me, so I would definitely 
argue in favor of this change.

> [...]
>
> Since the nested helper function is marked nothrow, a failed 
> assert throwing an AssertError or UnittestAssertError may 
> bypass the unittest's unwinding code (the compiler assumes 
> runTest never throws, so never installs stack unwinding code 
> around it), which means the scope(exit) never triggers and the 
> resource is leaked.

I guess the implication here is that assert shouldn't count as 
nothrow in unit tests? That won't help non-nested helper 
functions, of course, but they also won't throw 
UnittestAssertError (in this hypothetical), so that should be 
okay, from a safety perspective.

These don't seem like insurmountable problems, but the 
possibility that existing code might *rely* on AssertErrors from 
deep in the call stack being caught by the runtime is one I 
hadn't considered. Since there's no way to distinguish the 
legitimate uses of that "feature" from the actually-broken ones, 
it's hard to imagine a solution that fixes the latter without 
breaking the former.