[swift-evolution] Swift ABI Stability Manifesto
rjmccall at apple.com
Thu Jan 26 16:11:07 CST 2017
> On Jan 26, 2017, at 4:04 PM, Michael Ilseman via swift-evolution <swift-evolution at 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.
>> 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
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution