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

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.2328.1299539399.4748.digitalmars-d at puremagic.com...
> 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.
>

Thanks.

> 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.
>

Yea. I have a little bit of experience with JUnit/NUnit. Compared to that, 
assertPred is trivial and perfectly straightforward.