On 6/9/2021 10:54 AM, Timon Gehr wrote:
> AssertError is still *caught* /by the language/ on in contract inheritance.

That's a fault in the language design. I do make a mistake now and then :-/ All I can do is grovel and beg forgiveness.

On 6/8/2021 11:58 PM, Max Samukha wrote:
> Placing (part of) constructor logic into a separate function that may throw, and pretending that a partially constructed state is a valid state - why do you think it is better?

As I remarked, it makes the code easier to reason about.

On 6/9/2021 7:01 AM, Steven Schveighoffer wrote:
> I'm 99% sure we could have a nogc stack trace for InvalidMemoryOperationError if we had a nogc demangler. Everything else seems already nogc, just not fully marked.

I don't believe it would be hard to make a nogc demangler, even if it used malloc.

Even better, provide a "sink" parameter for the result, and have the demangler defer its final allocation needs to the caller, and free its temporary data itself.

On 6/8/2021 9:50 PM, Andrei Alexandrescu wrote:
> Code in class destructors needs special typechecking and be restricted. IIRC, among other things it wasn't supposed to assume references to other class objects are valid. This has been discussed several times but never implemented.

Probably because nobody ever filed a bugzilla entry for it?

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?

On Thursday, 10 June 2021 at 00:39:44 UTC, Mathias LANG wrote:
> On Wednesday, 9 June 2021 at 02:37:34 UTC, Walter Bright wrote:
>> [...]
>
> Actually we use `-checkaction=context` by default in our unittest build and it allocates even more :)
>
> [...]

There aren't that many constructors in general, lots of static methods / construct after variable declaration-ing.