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