> 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)
[…]
> 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)