> On Jan 26, 2017, at 4:04 PM, Michael Ilseman via swift-evolution > <swift-evolution@swift.org> wrote: > 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.
Right. We wanted to guarantee loadability for unowned references in general but had to walk it back because of ObjC interop; we could still make the stronger guarantee on a non-ObjC platform. But I'm fine with treating all weak references as memory-pinned even though our current native implementation doesn't technically require it. The big issue is whether we can completely define away memory-pinned types, and in my mind, even if we could do that today, it would be extraordinarily short-sighted to assume it forever. John. > > >> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
