I hate class destructors with a burning passion

[Mathias LANG]

On Wednesday, 9 June 2021 at 02:37:34 UTC, Walter Bright wrote:
> On 6/6/2021 4:54 AM, Mathias LANG wrote:
> > https://github.com/dlang/druntime/pull/3476/files
>
> Frankly, the whole jazz with assert() went way off the rails. 
> Assert should go directly to Jail, it should not pass Go or 
> collect $200. All these layers it goes through is just madness.
>
> 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.
>
> These sorts of things are why I added the checkaction switch to 
> bypass it and just do the simple, direct stuff.

Actually we use `-checkaction=context` by default in our unittest 
build and it allocates even more :)

But yeah, we should *not* consider `assert` as recoverable.
Which means we should not:
1) Catch them in contracts;
2) [Have unittests for assertion 
failures](https://github.com/dlang/phobos/blob/815a718c81f15e3155f95260b299ce1b7887664d/std/typecons.d#L3141-L3153)

Regarding point 2, we even have [special 
code](https://github.com/bosagora/agora/blob/fc210b69a6d8e9777935e6e368f318434e3df466/source/agora/test/Base.d#L118-L121) to handle this. Note that our application logs to a buffer in unittest mode, and we dump that buffer on assertion failure, so successful runs are silent and failing runs give you the full context.

> Throwing constructors is one of those things that makes a 
> program very hard to reason about. I've debated with Andrei 
> about requiring that constructors be nothrow. My advice is make 
> them nothrow, i.e. design them so they cannot fail. There's not 
> a single throwing constructor in DMD, and it's going to stay 
> that way :-)

Last time I checked, there's *nothing* that was throwing in DMD?