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 

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 <gless...@tffenterprises.com> 
> wrote:
>> On 25 janv. 2017, at 14:16, Michael Ilseman via swift-evolution 
>> <swift-evolution@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

swift-evolution mailing list

Reply via email to