>> 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

Reply via email to