<div dir="ltr"><div>I agree Karl, especially the bit about the difficulty of implementation being the limiting thing here.<br><br></div><div>I think the language devs must have some idea how this will work, but don&#39;t seem to want to share/discuss it at the moment. I was hoping for some feedback about my implementation ideas - whether they are along the right lines, or way off, or not necessary (because the implementation strategy is already known). Perhaps this the wrong list for that kind of discussion?<br><br></div><div>Anyway, I was thinking some more and I had another idea about implementation. This could be very useful for maintaining binary compatability in other areas too.<br><br>Implementation idea No. 4:<br><br>The basic concept is that the dynamic linker would fixup the offsets as well as relocating the addersses, allowing the size of objects (and maybe structs?) to change at link-time. The process might be something like this:<br><br></div><div>* References to members defined in extensions would compile to have an offset symbol instead of a value - so they can be fixed up later<br></div><div>* The linker would scan all the shared objects that are referenced (and thus might get linked)<br>* Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for each class.<br>* Append the extra fields (increase the size the class), decide where each member goes in the extended layout and fixup the offsets<br>* Carry on with normal relocation<br><br></div><div>There are quite a few assumptions in the above, and probably quite a few misunderstandings about how things work on my part too (I&#39;m not an expert at this), however I think it should work in principle. Some questions about my assumptions: Can linker know in advance all the potential modules that could be linked, or is this done more lazily and it only knows about what it&#39;s linking right now? Is it ok for the size to change - I don&#39;t know if it&#39;s a static sizeof() or if it could be (or already is) stored in the isa?<br></div><div><br></div><div>Would love to hear back from anyone who is familiar with the code if this sounds viable or not. I&#39;d love to go digging in there myself (I&#39;ve tried a few times but got lost) but I don&#39;t have time at the moment.<br><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 11 Oct 2016 at 08:19 Karl &lt;<a href="mailto:razielim@gmail.com">razielim@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
&gt; On 10 Oct 2016, at 21:15, Charles Srstka 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">
&gt;<br class="gmail_msg">
&gt; Right. The question is whether we *need* to add stored properties out-of-module, and what the use case for that is. To me it seems that adding them in-module is by far the more common use case, for the purposes of implementing protocols.<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; At any rate, the rewrite option would be a great addition to Swift regardless of what our answer to the first question is.<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; Charles<br class="gmail_msg">
<br class="gmail_msg">
I actually think out-of-module is the more common and important case. If you’re using a types from an external framework, it’s strange that you can retroactively add functionality but not additional data. That limitation, AFAICT, is purely due to implementation. Some well-constructed frameworks will allow you to add stored data to the types being used by subclassing. Not all are so well constructed, and as we have more and more value-types subclassing is not going to be a solution.<br class="gmail_msg">
<br class="gmail_msg">
You can add stored properties to objects in Python, which is one of the really great things about it. If you need to add a stored property to track some additional state you layer on top of a framework’s components, it’s staggering how easy it is - you don’t even need to define any new types.<br class="gmail_msg">
<br class="gmail_msg">
I personally think it’s important for Swift as a scripting language to have this ability - for value-types as well as classes, by default. We could optimise it away completely for types which aren’t public, and you should be able to explicitly declare a type non-extendable (similar to declaring it non-subclassable with ‘final’) to opt-out. I’m sure it will never happen, but there you go.</blockquote></div>