>> Benjamin:
>>
>> Implementation wise, weak does *not* currently have the effect of storing
>> associated values. It does however mean that any object with weak references
>> stays allocated after being deinited, until all the weak references are
>> evaluated and zeroed (they are not zeroed when the object deinits, zeroing
>> is done lazily. See
>> https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html
>> for a detailed discussion).
>>
>> However, this seems likely to change at some point when Greg's changes are
>> merged. Weakly referenced objects would cause a side-table to be allocated,
>> with the benefits that the object could be deallocated immediately after
>> deinit, and only the side-table would hang around (to service attempts to
>> access weak references, which would still be lazily zeroed). The small
>> disadvantage of this (which only applies to instances that actually have had
>> weak references) is that an extra pointer dereference is needed for retain,
>> release, and weak reference access (and some other things). But a big
>> advantage is that the side-allocation could be used for other things too,
>> like stored properties.
Thanks for the reference to the article. I always meant to take the time to do
that bit spelunking, never actually had the time, and the non-code
documentation I found claimed it was out of date so I didn't bother reading it.
Of all the possible implementations I conjectured after hearing about ARC when
it was announced for Obj-C, this was not one of them. And frankly, reading it
makes me want to quit working as a software developer and take up writing
psychological thrillers as my job. :(
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
