On Saturday, 24 September 2016 at 08:03:15 UTC, Martin Nowak
wrote:
On Friday, 23 September 2016 at 20:57:49 UTC, Nick Sabalausky
wrote:
were rejected because it was deemed both easy enough and
preferable to get these features by modifying DMD to add
behind-the-scenes AST magic to "assert".
So...umm...yea...whatever happened to that beefed-up "assert"
feature?
assertPred!"=="(a, b);
assertPred!"!"(a);
assertPred!(std.range.equal)(a, b);
assertPred!"==" looks like it asserts not equal, which is the 1st
problem with this, assertPred!"!=" looks even worse. I considered
going down this route but... ugh.
Seems to do most of what DIP83 does w/ expensive feature
design, and compiler implementation work.
Also http://code.dlang.org/packages/unit-threaded comes with a
couple of test comparators, though it follows ruby rspec's bad
idea of giving every comparator a name (which has to be learnt
and documented).
I didn't want to give every comparator a name, this was the least
bad option from my point of view. I'd rather `assert` be magical.
Or, be able to have AST macros to get around the limitations of
how operator overloading works in D. Don't get me wrong, the
reason why it works the way it does is awesome in general, but
limiting in this case in particular. I ended up implementing this:
foo.should == bar
But unfortunately it only works for equality. This is also
possible:
foo.should.not == bar
But I can't do the same with any of the other operators AFAICR so
I went with consistency even though the equality check is the
most common.
Atila
