I quite curious on the rational behind the decision, as currently it's not very attribute friendly, which makes destroy function @nogc for certain classes downright near impossible. From the time that I have looked into this issue(and from frequent discussions) many of the issues and bugs is the result of this bizarre design decision.

On Wednesday, March 28, 2018 20:17:28 12345swordy via Digitalmars-d wrote:
> I quite curious on the rational behind the decision, as currently it's not very attribute friendly, which makes destroy function @nogc for certain classes downright near impossible. From the time that I have looked into this issue(and from frequent discussions) many of the issues and bugs is the result of this bizarre design decision.

I think that this is the first that I've heard of them not being virtual, but if I had to guess, the reason is that class finalizers are called by the GC, and their TypeInfo is probably used, which would make it unnecessary for the finalizer to be virtual, because it would always be called directly rather than through a base class reference. But that's just a guess.

However, I don't understand why that would make the finalizer interact badly with attributes. If the finalizer is not virtual, then the attributes for each finalizer should be independent of one another. The reason that attributes and classes are normally a problem is because you're restricted by the attributes that were chosen for the base class function, and your options for choosing different attributes for the function in a derived class are limited.

As for issues with destroy in particular, remember that classes were designed to be constructed and allocated using the GC and then destroyed and freed by the GC. All of the stuff that tries to deal with any of that without the GC came later - including using destroy to destroy an object rather than waiting for the GC to do it. So, it's not exactly surprising if there were design decisions made that don't play well with something like destroy. Hopefully, any such problems can be fixed, but stuff like destroy is trying to work around how classes were designed to be used.

- Jonathan M Davis

On Thursday, 29 March 2018 at 01:59:11 UTC, Jonathan M Davis wrote:
> On Wednesday, March 28, 2018 20:17:28 12345swordy via Digitalmars-d wrote:
>> [...]
>
> I think that this is the first that I've heard of them not being virtual, but if I had to guess, the reason is that class finalizers are called by the GC, and their TypeInfo is probably used, which would make it unnecessary for the finalizer to be virtual, because it would always be called directly rather than through a base class reference. But that's just a guess.
>
> [...]
Honesty the finalizer and destructor should be split up if we introduce memory allocation without the GC, as finalizer is something that the GC uses and shouldn't be touch by anything else.

I wish they give us some a little overview with ProtoObject.

On Thursday, 29 March 2018 at 15:09:49 UTC, 12345swordy wrote:
> Honesty the finalizer and destructor should be split up if we introduce memory allocation without the GC, as finalizer is something that the GC uses and shouldn't be touch by anything else.
>
> I wish they give us some a little overview with ProtoObject.
Btw ._dtor symbol not being virtual makes it downright impossible to make destroy function attribute friendly.