<div dir="ltr">Interestingly, if all the stored properties defined in extensions could be determined at link-time, the size/layout of the side-table could include them directly, removing the need for further indirection. The offsets would still need to be fixed up, which would add some complexity to the implementation.<br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 12 Oct 2016 at 00:54 Jay Abbott &lt;<a href="mailto:jay@abbott.me.uk">jay@abbott.me.uk</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg">Wow, that&#39;s a very interesting post. Sounds a lot simpler to implement than my idea about fixing up offsets in the linker and preserves binary compatability just the same.<br class="gmail_msg"><br class="gmail_msg">I got some complaints when I first started talking about this that the runtime would have to track extra pointers and performance would be affected because of additional levels of indirection, which I didn&#39;t fully understand because it seems fairly trivial to me. Perhaps this twin-purpose refcount/side-table pointer also suffers the same concerns?<br class="gmail_msg"></div></div><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, 12 Oct 2016 at 00:21 Ole Begemann via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> &gt; I think the language devs must have some idea how this will work, but<br class="gmail_msg"><br class="gmail_msg"> &gt; don&#39;t seem to want to share/discuss it at the moment. I was hoping for<br class="gmail_msg"><br class="gmail_msg"> &gt; some feedback about my implementation ideas - whether they are along the<br class="gmail_msg"><br class="gmail_msg"> &gt; right lines, or way off, or not necessary (because the implementation<br class="gmail_msg"><br class="gmail_msg"> &gt; strategy is already known). Perhaps this the wrong list for that kind of<br class="gmail_msg"><br class="gmail_msg"> &gt; discussion?<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">For what it&#39;s worth, Greg Parker (Cc&#39;ed) started a discussion back in<br class="gmail_msg"><br class="gmail_msg">March that I think is relevant here:<br class="gmail_msg"><br class="gmail_msg"><a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001424.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001424.html</a><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Here&#39;s the relevant part:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&quot;I am considering a new representation for Swift refcounts and other<br class="gmail_msg"><br class="gmail_msg">per-object data. This is an outline of the scheme. Comments and<br class="gmail_msg"><br class="gmail_msg">suggestions welcome.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Today, each object stores 64-bits of refcounts and flags after the isa<br class="gmail_msg"><br class="gmail_msg">field.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">In this new system, each object would store a pointer-size field after<br class="gmail_msg"><br class="gmail_msg">the isa field. This field would have two cases: it could store refcounts<br class="gmail_msg"><br class="gmail_msg">and flags, or it could store a pointer to a side allocation that would<br class="gmail_msg"><br class="gmail_msg">store refcounts and flags and additional per-object data.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Advantages:<br class="gmail_msg"><br class="gmail_msg">…<br class="gmail_msg"><br class="gmail_msg">* Allows inexpensive per-object storage for future features like<br class="gmail_msg"><br class="gmail_msg">associated references or class extensions with instance variables.<br class="gmail_msg"><br class="gmail_msg">…&quot;<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">I don&#39;t know the current status of this idea (implemented? planned?<br class="gmail_msg"><br class="gmail_msg">abandoned?). Also, it&#39;s worth noting that this would only apply to<br class="gmail_msg"><br class="gmail_msg">classes, not value types.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Ole<br class="gmail_msg"><br class="gmail_msg">_______________________________________________<br class="gmail_msg"><br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class="gmail_msg"></blockquote></div></div></blockquote></div>