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

[Charles Srstka]

> On Oct 16, 2016, at 6:56 PM, Benjamin Spratling via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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 <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.  :(

The implementation in Objective-C ARC was not the same as Swift's, IIRC. I believe that it zeroed the references out immediately at the time the object ran out of references, rather than doing it lazily the next time something tried to access the reference. I could be wrong, though.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161016/6d276ba4/attachment.html>