[swift-evolution] Swift ABI Stability Manifesto

[Michael Ilseman]

Weak references will most likely not be bitwise-movable on all platforms.

In order for a weak reference to be nil-ed out, the weak reference itself must, conceptually, be referenced. There may be many convoluted schemes that can serve as alternatives, but a straight-forward (and pragmatic) approach would make the weak reference address-only. That is, something elsewhere has taken and stored its address so that it can nil-out the weak reference when the objects that it references is destroyed. At that point, it can’t just be bitwise-moved, as that would result in a dangling reference to the weak reference. One approach to implementing this is a global table mapping class instance addresses to weak reference addresses that need to be nil-ed out. Alternatively, the class instances could store a list of the addresses of weak reference to themselves. Either way, if the address of the weak reference changes, something somewhere else in memory must be updated. Thus, they are not bitwise-movable.

This is not true for unowned references, which can be implemented without their address being taken, e.g. by a separate ref count.


> On Jan 25, 2017, at 10:30 PM, Guillaume Lessard <glessard at tffenterprises.com> wrote:
> 
> 
>> On 25 janv. 2017, at 14:16, Michael Ilseman via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> An example of a type that is neither trivial nor bitwise movable is a struct containing a weak reference. Weak references are tracked in a side table so that they can be nil-ed out when the referenced object is destroyed. When moving an object of such type from one address to another, the side table must be updated to refer to the weak reference's new address.
> 
> Isn’t this specifically a description of @objc weak references? Would weak references with no compatibility mode (e.g. on Linux) be bitwise-movable?
> 
> Thanks for the illuminating document!
> 
> Guillaume Lessard
>