• 12345swordy (6/6) Mar 28 2018 I quite curious on the rational behind the decision, as currently
• Jonathan M Davis (22/28) Mar 28 2018 I think that this is the first that I've heard of them not being virtual...
• 12345swordy (7/17) Mar 29 2018 Honesty the finalizer and destructor should be split up if we
• 12345swordy (3/8) Mar 29 2018 Btw ._dtor symbol not being virtual makes it downright impossible

12345swordy <alexanderheistermann gmail.com> writes:

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.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

12345swordy <alexanderheistermann gmail.com> writes:

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.

12345swordy <alexanderheistermann gmail.com> writes:

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.