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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to