I wrote a lot of code predicated on being able to clean up
unowned references in the deinitializers of their
unowned object. Lo and behold, that is not a feature of
unowned references. But apparently it is of
unowned(unsafe) references, at least that is the way it appears to be working right now — what once caused a crash accessing an
unowned reference during its object's deinitialization, now is no longer crashing and is working as expected.
If guaranteed that all
unowned references will not be accessed after deinitialization of their object, would it be safe to use it?
For more details, the aforementioned cleaning up entails removing the object from a set where the hashability is based off its contents' object identities. So if it's a plain
unowned reference, when the set attempts to access its hash, it will crash if that procedure is being performed while the object is already deinitializing.
The reason the objects aren't removed from the set before they are deinitialized is because this code is a component of library that enables the addition of nodes to a directed acyclic graph. As a feature, I decided that I would not require consumers of the library to have to remove the nodes when they're done with them, they can simply add them to the graph, then when they're done, release their object (the node) as they would anyways, and because the library adds listeners onto the nodes to remove them from the graph in their deinitializers, it was anticipated that it wouldn't be a problem — that the graph would be able to be cleaned up transparently. Obviously it's a little more complicated now that it's apparent that
unowned(safe) references can't be accessed while the object they're referencing is deinitializing.
unowned(unsafe) works in the way it appears to, it would be a solution to this problem.