Finalizers are tricker than you might think. Part 2
8 comments
·March 28, 2025saagarjha
pjmlp
Those that don't keep up with WWDC talks are going to be even more surprised, given the changes on how ARC works across Swift versions.
Going back to finalizers, while they seemed a great idea since Smalltalk days, they have proven otherwise, and that is why nowadays they are largely deprecated.
In Java, and as of last Go's version, there are alternative ways with classical finalizers being "deprecated for removal" in Java's case, and on .NET SafeHandles and IDispose pattern is the way.
xxs
Java has had PhantomReferce for about 25y now. There are meant for post-mortrem clean up. (although both finalize and PhantomReferce are pre-mortrem, unlike WeakRefences)
One of the main issues with finalize method is that it adds the newly created objects (prior to invoking the c-tor) to a (effectively) global queue which has rather negative perf. impact. The happens-before semantics also work in a weird way, e.g. fields set in the c-tor may not be visible in finalize().
Finalize/clean up code is still needed to ensure proper freeing of non-managed 'objects'. They are more of a defense mechanism in most cases as close/dispose is the correct way.
immibis
PhantomReference solves the problem where objects can be resurrected during finalization, not the problem where objects can be finalized while you're still "using" them.
The same happens in ARC code as well. People expect scope-based lifetimes and are surprised to learn about “last use” rules.