<div dir="ltr">How much would convenient method forwarding when wrapping change how desirable this feature is? I am hesitant to add storage to already allocated instances if we can avoid it. </div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Greg:<br><br></div><div>I've CCed you in case you want to respond to my comments below about potentially optimising "extensionIvar" access without using a dictionary. See my response to Haravikk below.<br></div><div><br>Benjamin:<br><br>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 <a href="https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html" target="_blank">https://www.mikeash.com/<wbr>pyblog/friday-qa-2015-12-11-<wbr>swift-weak-references.html</a> for a detailed discussion).<br><br>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.<br><br></div>Haravikk:<br><br></div><div>It can be done efficiently using Greg's proposed changes. The current implementation on his branch (<a href="https://github.com/gparker42/swift/tree/new-refcount-representation" target="_blank">https://github.com/gparker42/<wbr>swift/tree/new-refcount-<wbr>representation</a>) does not have any extra space for stored properties, but he has discussed "extensionIvars" before on swift-dev, and proposed that the side-table structure contains a pointer to a dictionary for these. However, I think with some dynamic loader magic this could be implemented as a dynamic structure instead of a dictionary. Each time a module is loaded, the side allocation for stored properties could be extended and the offsets to the newly extended properties could be fixed-up based on the current size. Existing instances could be handled by using the structure size as a version number (stored at the beginning of this area), it would check if the instance is at the current version and migrate/update the structure as needed (realloc it and init the extended area to zero, updating the size/version field). These checks would be less overhead than a getter/setter function call, so using dot notation to access the properties would not be deceiving programmers about the cost.<br><br></div>Anton:<br><br></div>Why should it matter where data is stored? Can you expand on any reasons for wanting object data to be contiguous, or thinking that it shouldn't be allowed for Swift classes?<br></div><br></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>