[swift-evolution] stored properties in extensions (was: associated objects)

[Benjamin Spratling]

>> 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.  :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161016/a423fdf3/attachment.html>