On Friday, 29 August 2014 at 19:01:51 UTC, Andrei Alexandrescu
wrote:
On 8/29/14, 3:53 AM, "Marc Schütz" <[email protected]>" wrote:
Jacob Carlborg just recently brought this up in another
thread. Isn't it
kind of consensus that calling a destructor from the GC is not
a good
idea because of the restrictions that apply in this context?
Andrei even
wanted to deprecate destructors for classes because of this.
Maybe a
better direction would be to separate the concepts of
destruction and
finalization, and introduce two kinds of "destructors" for
them.
I think we need to stay with what we have. Adding a distinct
kind of destructor might be interesting. -- Andrei
Our idea was that an additional destructor (let's call it a
finalizer) would be helpful because it is backward compatible.
The compiler could make some validity checks on it, at the least
make it nothrow, maybe @nogc (but I believe we can relax this
restriction), pure (?). Disallowing access to references (because
they could pointer to already destroyed objects) is unfortunately
not feasible, because we can't distinguish GC pointers from other
ones. To avoid the need for code duplication, finalizers could
always be called implicitly by destructors (assuming everything
that is allowed in finalizers is also permitted in destructors).
Calling destructors from the GC could later be phased out. It is
technically not a breaking change, because there never was a
guarantee that they'd be called anyway.
