Making AssertError a singleton

[Timon Gehr via Digitalmars-d]

On 13.12.2016 17:47, Andrei Alexandrescu wrote:
> On 12/13/2016 11:39 AM, Timon Gehr wrote:
>> On 13.12.2016 01:57, Andrei Alexandrescu wrote:
>>> On 12/12/16 4:35 PM, Brad Roberts via Digitalmars-d wrote:
>>>> Of course, then you'll find the fun of all the tests (and probably
>>>> code)
>>>> that catch AssertError.
>>>
>>> You can catch AssertError. There's no guarantees dtors have been called
>>> during unwinding. -- Andrei
>>
>>
>> If 'in'-contracts are not allowed to corrupt the program state, then I
>> don't really see how implementations will be able to not call dtors.
>
> One way to accomplish that is to have assert work differently when
> called from within contracts. (I'm not sure whether that's currently
> done that way.) -- Andrei

I assume you don't refer to passing along a runtime flag whether 
execution is currently in a contract and then selectively disable 
calling of dtors.

So I think you are suggesting a breaking change in language semantics:

void myAssert(bool x){
     // this function could be in a different compilation unit
     assert(x);
}

class C{
     void foo(int a)in{
         myAssert(a>0);
     }body{

     }
}
class D:C{
     override void foo(int a)in{
         myAssert(a<0);
     }body{

     }
}

void main(){
     D d = new D;
     d.foo(1);
     d.foo(-1);
}


(Using 'assert' for specifying contracts is a questionable design 
decision anyway: it is not possible to distinguish implementation bugs 
in the contract code and functions it calls from contract violations.)