Bits and Side Tables: How Reference Counting Works Internally in Swift

> When the strong refCount went to zero but there were weak references remaining, the object was deinitialised but not deallocated: it stuck around in a “zombie” state.

[…]

> Surprise, surprise, unowned references are basically implemented the same way as pre-Swift-4 weak references.

I see a possible improvement there: instead of not freeing the memory of an object, tell the memory allocator “you can take back all of this allocation, except for the first headersize bytes” (a realloc to a smaller size that guarantees to not move the object).

That would require extending the API of the memory allocator, and thus, make it impossible to swap in a different C(++)-style allocator, but would decrease the size of those zombie object remnants that hang around (probably to 16 bytes, on 64-bit systems)