I hate class destructors with a burning passion

[Steven Schveighoffer]

On 6/10/21 9:09 AM, FeepingCreature wrote:
> On Thursday, 10 June 2021 at 12:59:59 UTC, Steven Schveighoffer wrote:
>> On 6/10/21 8:07 AM, Kagamin wrote:
>>> On Wednesday, 9 June 2021 at 17:54:06 UTC, Timon Gehr wrote:
>>>> On 09.06.21 04:37, Walter Bright wrote:
>>>>>
>>>>> Allocating via the GC is in assert is just ridiculous, as the 
>>>>> program is going to exit shortly anyway. There won't ever be a need 
>>>>> to run a collection on it. Just malloc away and fuggeddabootet.
>>>>
>>>> AssertError is still *caught* /by the language/ on in contract 
>>>> inheritance.
>>>
>>> I'd say, lower assert failures in contracts to a different function, 
>>> say, _d_contractFailed(), which can do a different thing, say, throw 
>>> ContractError, and child contract can catch only this specific 
>>> ContractError instead of any Error.
>>
>> What about asserts in functions called by the contract? I guess 
>> technically they are not part of the contract, just poor coding, but 
>> people may rely on those asserts in some cases.
>>
> 
> All the more reason to throw `ContractError` instead of `AssertError`. 
> Asserts in an unrelated function should not be caught as part of 
> in-condition processing.

What about asserts in a related function? The foundation of programming 
with functions is that you can abstract common implementation into 
another function.

I could easily see someone making a helper function for lots of similar 
contracts.

It's an easy fix, just use to-be-implemented "contract_assert" which 
throws the right error, but the change would break code that exists. A 
deprecation might be painful (probably only triggered at runtime, so you 
might not catch all your cases).

-Steve