What's up with the assert enhancements proposed years ago?

[Jonathan M Davis via Digitalmars-d]

On Friday, September 23, 2016 23:50:03 Nick Sabalausky via Digitalmars-d 
wrote:
> On 09/23/2016 11:47 PM, Nick Sabalausky wrote:
> > On 09/23/2016 07:57 PM, Jonathan M Davis via Digitalmars-d wrote:
> >> On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d
> >>
> >> wrote:
> >>> So...umm...yea...whatever happened to that beefed-up "assert" feature?
> >>
> >> [...]
> >
> > Ugh, so, "It was rejected for being library instead of assert, then it
> > was rejected for being assert instead of library".
> >
> > /facepalm

Indeed. :(

> > Guess I'll just have to try getting used to awful Java-isms like
> > x.notEqual(y) :(
>
> And then that leads too, to the question of whether such third-party
> asserts are a good idea for the doc unittests I like so much... :/

I'd say not. If you're writing a library for general consumption, I don't
think that anyone else who is not actually helping to develop it should have
to know or care what unit testing facilities you're using. assert is
universal and clear, whereas other stuff is not universal and may or may not
be clear to those not familiar with it.

Also, my take on it is that ddoc-ed unittest blocks are really there to just
give examples for the documentation, not to test your code. You want the
examples tested so that you know that they work - which is why ddoc-ed
unittest blocks are such a great feature - but it's not their purpose to
test your library. It would be wholly unreasonable to have thorough tests in
the documentation, and what makes a good example doesn't necessarily make
for a very good test (or vice versa).

So, you can just use basic assertions in your examples without really
impacting your actual tests. You then have separate unittest blocks that
have the full set of tests needed to verify full functionality, and those
can use whatever unit testing tools you prefer without affecting anyone
reading the documentation.

- Jonathan M Davis