[phobos] Silent failure of std.container unittests

[Jonathan M Davis]

On Thursday, July 15, 2010 15:43:47 Andrei Alexandrescu wrote:
> 
> There's one more problem with this, which should be discussed - an
> assert inside e.g. sqrt or any function that sqrt transitively calls
> _does_ stop the entire thing. So assert has different semantics
> depending on locus, which I hope we agree is not a desirable trait.
> Also, as you mentioned, if someone throws, we're again back to a
> different semantics.
> 
> I think there's a disadvantage there. FWIW changing the semantics of
> assert that way will translate into a disincentive to use it inside
> unittests ("Hmm, I better use enforce() here because assert() is just
> weird.")

If there are folks (like Walter) who want to report a failure and continue with 
the assertions without creating separate unit test blocks, then I'd suggest 
creating a function specifically for that - such as assert_nothrow(). Since the 
tests are already indicating failure based on a flag, such a function could set 
that flag so that failure could be indicated, while assert would continue to have 
its normal semantics, throwing from the block, and indicating failure.

I think that it's a huge mistake to make assert have different semantics in unit 
tests. And honestly, since every other unit testing framework has functions 
instead of unit test blocks, and those functions stop execution when an 
assertion fails (since an exception is thrown), you have to create whole 
functions for each test that you want separate. That's a lot to worry about than 
simply adding an extra unittest block - especially if you make the whole thing 
one line.

If D chooses to have assertions not stop the execution of a particular unit 
test, block then that will confuse new users - both with regards to the behavior 
of assertion being different and the fact that the unittest block didn't cease 
executing after the first failure like occurs in most unit testing frameworks. In 
fact, if I it hadn't seen discussions about it in the newsgroup, then I would 
have thought that assertion failing to cease the excecution of the unittest 
block was an error that needed fixing, and I would have reported it to bugzilla. 
It totally breaks the normal behavior of assert.

I think that it would be a huge mistake for assert's semantics to change based 
on context. If we really need a non-throwing assert, we should add a function 
specifically for that rather than subverting assert.

- Jonathan M Davis