On Sunday, 6 June 2021 at 11:54:40 UTC, Mathias LANG wrote:

extern(C++) class support is critically incomplete/buggy right now, even for basic usage that doesn't involve templates or multiple inheritance. Are you aware of these bugs?

Issue 21693 - extern(C++) class instance dtors are never called, breaking RAII:
https://issues.dlang.org/show_bug.cgi?id=21693

Issue 21690 - Unable to dynamic cast extern(C++) classes
(Dynamic casts of extern(C++) classes are silently lowered to unchecked static casts):
https://issues.dlang.org/show_bug.cgi?id=2169

On Sunday, 6 June 2021 at 18:55:47 UTC, Guillaume Piolat wrote:

Do we have an issue or two for that? Sounds like an enhancement. Should/would it be configurable? Like -gcClassDtors=yes/no/auto kind of a thing or just kill it.

On Sunday, 6 June 2021 at 19:00:48 UTC, Guillaume Piolat wrote:

Conventions do not scale.

On Monday, 7 June 2021 at 10:04:32 UTC, Imperatorn wrote:

GC.inFinalizer was added specifically to address this issue.

if(GC.inFinalizer) {
  // no GC or deterministic stuff allowed here
}
else {
  // do whatever you want
}

So if you need GC or deterministic stuff in a class destructor, you can invoke it manually and still let the GC worry about cleaning up the memory.

The alternatives (adding a separate finalizer, or preventing the GC from calling destructors) are massively breaking changes, so I don't see that happening. Even had destruction and finalization been separate from the beginning, I'm sure people would have misused the finalizer anyway just as they did in older versions of Java.

On Monday, 7 June 2021 at 10:51:02 UTC, Mike Parker wrote:

Breaking changes for memory management are eventually needed, but they should not come one after another. It has to be designed as a whole.

So, if you want finalization, you need to start by making strongly typed unions and enable precise collection.

On Monday, 7 June 2021 at 10:04:32 UTC, Imperatorn wrote:

That the GC would not call class destructors have been proposed by Alexandrescu in this very community, which kindly rejected the change, years ago.

This can be done if everyone first jump into the deterministic destruction wagon, since programs are currently accidentally correct. But you'll find that people do not agree on the problem.

So, in the absence of consensus, idioms like the one I posted are what we have right now.

On Sunday, 6 June 2021 at 11:54:40 UTC, Mathias LANG wrote:

Should not we not using this?

https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/

On Monday, 7 June 2021 at 12:17:18 UTC, Guillaume Piolat wrote:

See_also: https://forum.dlang.org/post/ljrm0d$28vf$1@digitalmars.com

On Monday, 7 June 2021 at 10:28:32 UTC, Ogi wrote:

Ignore classic solutions, get classic problems.

On Sunday, 6 June 2021 at 11:54:40 UTC, Mathias LANG wrote:

As I understand, this code unintentionally accesses thread local connection pool in multithreaded manner without synchronization?