RFC: Change what assert does on error

[Derek Fawcus]

On Sunday, 6 July 2025 at 15:34:37 UTC, Timon Gehr wrote:
>
> Contracts rely on catching assert errors. Therefore, a custom 
> handler may break dependencies and is not something I will take 
> into account in any serious fashion.

Given the spec for contracts, isn't this just an unspecified 
implementation detail which could be changed?

i.e. although the in and out expressions are 'AssertExpressions', 
they do not need to be implemented by calling assert().  So one 
could define a new form of Throwable, say ContractFail, and have 
that thrown from the contract failure cases.

Similarly with the asserts within class invariant blocks, and for 
asserts within unittest blocks; but here there is a weaker 
argument, as those use explicit calls to assert.  However even 
then, the spec says that they have different semantics in 
unittest and in contracts.

Each of these could then have its own definition for if the call 
stack is unwound. Which allows for raw asserts to then have a 
different behaviour if desired.

Otherwise the only other apparent way to have 'traditional' 
assert would be for it to be a library routine (of whatever new 
name) which simply does the message followed by abort(). It 
strikes me that this is essentially the only way at the moment to 
guarantee that.