std.unittests vote tally

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Feb 8 07:27:55 PST 2011


Vote has closed last night at 23:59:59:99, but I accepted Lars' late vote.

Thanks Jonathan for responding to comments and suggestions, and for a 
very dedicated attitude throughout.

YES votes mean wholesale acceptance of the library. NO means either 
partial acceptance or no acceptance at all.

We have eight NOs and even YESs. (In fairness I have changed my vote 
after Don committed to improve assert(), but forgot to submit it.)

NO:

SHOO (arguments: unittest code should be easy to read without prior 
knowledge)
Don (arguments: assertPred is harder to read than assert, "don't use if 
you don't like" doesn't apply to Phobos, Phobos becomes difficult to 
read if we continue adopting clever functions, something that has any 
appearance of being complicated needs VERY strong justification. Voted 
yes for assertThrown and assertNotThrown. Asked for bugzilla enhancement 
requests to have assert obviate assertPred)
Michel Fortin
Brad Roberts
David Nadlinger (yes for assertThrown, 50/50 for assertNotThrown and 
collectExceptionMsg, no for assertPred)
spir (yes to assertThrown, abstain for assertNotThrown and 
collectExceptionMsg)
Jim (reiterates that at best assert should be improved)
Lars T. Kyllingstad (on the fence with assertPred)

YES:

Jens Mueller
bearophile
Andrej Mitrovic
Nick Sabalausky
Andrei Alexandrescu (contingent on reducing the size of examples)
Masahiro Nakagawa (with a few notes)
Andrew Wiley

Reviewer Manager's decision:
============================

We have had an unexpected development: we can change assert() to obviate 
assertPred(), and Don all but promised he'll look into it. This means if 
we accept the library as it is, we'll look at a function on the brink of 
deprecation for the sake of a short-term benefit. Perhaps this is not 
the best course of action.

So let's not put assertPred() for now in Phobos, though Jonathan is to 
be commended for his work which is leading to a vast improvement to a 
core facility.

assertThrown seems to be liked by a vast majority - please add to 
std.exception at your earliest convenience.

assertNotThrown and collectExceptionMsg are on the fence and it's 
unclear whether some "NO" voters want them as isolated functions. Let us 
take a one-week vote for each. I will create one thread for each.


Thanks to everyone for participating, and special thanks to Jonathan!

Andrei


More information about the Digitalmars-d mailing list