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

[Atila Neves via Digitalmars-d]

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