On Thursday, 28 August 2014 at 18:53:25 UTC, Jacob Carlborg wrote:
On 2014-08-28 11:16, "Marc Schütz" <[email protected]>" wrote:
I'd rather introduce a special method that is called only by
the GC.
Cleaning up after an object that goes out of scope has always
been the
task of the regular destructor, it's undeterministic
destruction that
needs special treatment.
I was think about not breaking code. But introducing a new
function that is called by the GC which also calls the regular
destructor might work.
The other way round would be safer: A destructor automatically
calls as its first step a finalizer (let's use that term for a
destructor called by the GC) if present, but a finalizer doesn't
call the destructor. Remember that the things that are forbidden
in a finalizer are usually fine in normal destructors. By calling
the destructor from inside the finalizer, you bring all the
problems back that you wanted to get rid of by introducing a
special finalizer, right?
And this would be backwards-compatible: There is already today no
guarantee that a destructor gets called by the GC, so never
calling it doesn't break any valid code, strictly speaking. Then
you could place "safe" cleanup actions (like closing a file) into
the finalizer, and "unsafe" ones (like removing yourself from a
linked list) into the destructor, and you don't need to duplicate
the actions from the finalizer in the destructor. The compiler
might then even detect unsafe operations in the finalizer and
refuse to compile them.
