Not that I have a say in this matter, but although I think the code is excellent in technical merits, is not a central part of the problem it aims to mend actually an insufficiency in druntime?
I'd rather see the regular, language provided assert() fulfilling the needs as the assertion mechanism. Why would it otherwise be there? It would be like a language feature that nobody uses because it isn't good enough.. :/ Jim Jonathan M Davis Wrote: > There are a number of people who have responded positively to my unit test > functions - including assertPred - as it has moved through the review > process. > Please reiterate that positive vote here (or negative if you're so inclined). > The deadline for votes is today. > > As it stands, I believe that assertThrown, assertNotThrown, and > collectExceptionMsg will clearly pass the vote, but it's not so clear if the > vote is in favor of assertPred. Going off just the votes in this thread, I > believe that it would be a tie as to whether assertPred made it in or not. > But > if we took the votes for the group of functions as a whole from previous > posts, > I believe that it would get in. It would be better though if such votes were > confirmed here - especially if the vote is close. I'd prefer not to have an > ambiguous vote. > > So, please vote. > > - Jonathan M Davis
