On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer
wrote:
On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven
Schveighoffer wrote:
On 7/26/17 2:33 PM, Moritz Maxeiner wrote:
A finalizer may freely work on non-pointer members and pointer
members that target objects outside the GC pool which the
programmer knows to be valid at finalization (e.g. they are
manually managed).
Whether or not it makes sense for the finalizer to call the
destructor is something the programmer has to decide on a per
use case basis.
No, because a destructor can safely assume it can look at GC
members' data. So a finalizer can never call it.
No, whether a finalizer can safely call a destructor depends on
the destructor's body.
If the destructor doesn't access GC members and doesn't allocate
using the GC, the finalizer can safely call it. That's why it's
the programmer's job to determine this on a use case basis.
The destructor is ensured that the entire structure is
intact, so it can do whatever it wants.
The point is that I saw (and see) no reason for a destructor
to ever call a finalizer.
An example:
class File
{
int fd;
ubyte[] buffer;
// avoiding bikeshed issues by using clear names
destructor() { finalizer(); delete buffer; }
finalizer() { close(fd); }
}
No reason to repeat the finalizer code in the destructor.
I concede the point.
