[dmd-internals] assert inside unittest sucks

[Benjamin Shropshire]

Jason House wrote:
> On Jun 27, 2010, at 11:32 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:
>
>   
>> Has anyone played with the new assert semantics? I find them a significant step down from before.
>>     
>
> No, and I'm not looking forward to it either! My asserts are sprinkled in unittests, helper functions, contracts, and in the main codebase. The current scheme is unnatural for me.
>
>
>   
>> Consider:
>>
>> int x;
>> ...
>> assert(x == 2, text(x));
>>
>> I'm not seeing an actual message informing that an assertion has failed! In case it does fail the text is just printed and as such it is indistinguishable from regular debug chatter.
>>
>> Walter, please revert the semantics of assert. This can't be worked with.
>>
>> If you do want to improve things, please have assert abort the current unittest and continue to the next one. The current semantics is unbearable.
>>     
>
> This is the basic scheme I had assumed before reading through the changeset. I can't appreciate Walter's performance concerns since I don't really know their impacts. I naïvely assume a global could be set which changes behavior from an abort to an error (exception)
>   

For that matter why should asserts use the same code gen inside unittest 
as out? Yes I know it's just easier to do it that way but but while 
making them different is non-trivial (I assume) I can't think it would 
be hard enough to rule it out. There is already more than one way they 
get implemented (with and without -release) and other things (like 
break/continue/goto/return, inside and out a foreach via opApply) 
radically change implementation depending on context.