<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'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'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's linking right now? Is it ok for the size to change - I don't know if it'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'd love to go digging in there myself (I've tried a few times but got lost) but I don'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 <<a href="mailto:razielim@gmail.com">razielim@gmail.com</a>> 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">
> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> 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">
><br class="gmail_msg">
> 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">
><br class="gmail_msg">
> 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>