On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
On Wednesday, June 28, 2017 01:11:35 Moritz Maxeiner via
Digitalmars-d-learn wrote:
Not every class can't be finalized, so it might make sense for
finalization to remain an available option.
There are definitely cases where finalizers make sense. Case in
point: if you have a socket class, it makes perfect sense for
it to have a finalizer. Yes, it's better to close it manually,
but it will work just fine for the GC to close it when
finalizing the class object so long as you don't use so many
sockets that you run out before the GC collects them. So,
having a finalizer is a good backup to ensure that the socket
resource doesn't leak.
Yes, I think that's like the File class I presented (at least on
Posix).
But on the other hand, since there are also cases in which
finalization of an alive (==undestroyed) object are unacceptable
(e.g. when it requires other GC managed objects to be alive),
splitting them off into two separate methods and allowing to
forbid finalization seems sensible to me.
