Better assert's status? (Was: Proposal for std.path replacement)

[Jonathan M Davis]

On Monday, March 07, 2011 12:43:00 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.2297.1299478837.4748.digitalmars-d at puremagic.com...
> 
> > On Sunday 06 March 2011 21:57:30 Nick Sabalausky wrote:
> >> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> >> news:mailman.2293.1299467610.4748.digitalmars-d at puremagic.com...
> >> 
> >> > I _was_ thinking of putting forward a new proposal which includes the
> >> > unit testing functionality that assertPred had which won't end up in
> >> > an improved
> >> > assert,
> >> 
> >> Speaking of which: Now that assertPred has been rejected on the grounds
> >> of
> >> an improved assert that doesn't yet exist, what is the current status of
> >> the improved assert?
> > 
> > There's an enhancement request for it:
> > 
> > http://d.puremagic.com/issues/show_bug.cgi?id=5547
> > 
> > I have no idea of any work is actually being done on it or not. It hasn't
> > actually been assigned to anyone yet, for whatever that's worth.
> > Honestly, it
> > wouldn't surprise me if it doesn't happen for a while. I'm not sure that
> > anyone
> > who is capable of doing it is particularly motivated to do it (though I'm
> > not
> > sure that they're _not_ either). It was clear that a number of people
> > wanted
> > assert to be smarter rather than having assertPred, but it isn't clear
> > that
> > assert is going to be made smarter any time soon. I suspect that it will
> > be a
> > while before it's done. We'll have to wait and see though.
> 
> Yea, that's what I figured, and that's why I was strongly in favor of
> assertPred despite the "promise" of assert improvements.
> 
> You're the sole author of assertPred, right? Do you mind if I include it in
> my zlib/libpng-licensed SemiTwist D Tools library (
> http://www.dsource.org/projects/semitwist ) ? I already have an
> assert-alternative in there, but assertPred is vastly superior. (Although,
> my assert-alternative does save a list of failures instead of immediately
> throwing, which I personally find to be essential for unittests, so I would
> probably add the *optional* ability to have assertPred do the same.)

Yes. I'm the sole author. Feel free to re-use it. It's under Boost, so you can 
use it for whatever Boost lets you do with it, and even if what you're doing 
isn't Boost compatible, it's fine with me if you use it anyway.

I do intend to take some of its functionality which assert will never have (such 
as assertPred!("opCmp", "<") or assertPred!"opAssign") and make another proposal 
to add those, but that's going to have to wait until other stuff is reviewed, and 
it doesn't help with what assert is supposed to be doing anyway (such as 
assert(a == b)).

I would really liked to have gotten assertPred into Phobos, fancy assert or no, 
but too many people just wanted assert to be better and thought that assertPred 
was unnecessary, overcomplicated, and/or overkill.

- Jonathan M Davis