<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">This article has helped me a lot:<div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift/blob/master/docs/ABI.rst" class="">https://github.com/apple/swift/blob/master/docs/ABI.rst</a></div><div class=""><br class=""></div><div class="">And generally all the documents in the docs folder will paint a nice picture of what to expect. Not that I would say that I fully understand the ABI, but I think that after reading all the docs I will have a better way of understanding what to expect.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 11, 2016, at 1:33 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Right, I understand that part. ABI stability means that we can run past binaries without recompiling.<div class=""><br class=""></div><div class="">What I want to know is what sorts of things affect this stability and which things don’t. I guess I want heuristics for knowing whether an idea will affect the ABI, and thus needs to be talked about now. I don’t want to distract from the process by proposing features which can be tackled later, but at the same time I REALLY don’t want to wait until phase 2 and then be told the feature can never be added because it would break the ABI (and I should have proposed it during phase 1).</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 11, 2016, at 4:24 AM, Anton Zhilin <<a href="mailto:antonyzhilin@gmail.com" class="">antonyzhilin@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Could someone explain in simple terms what the ABI is and what sorts of things might affect it?<br class="">
<br class="">
I had thought it was the layout in memory of structs/classes/etc… and how the program knows where to go to find a particular field. This seems to be incorrect though, as I have seen many features that I would assume have some affect on this layout ruled “out of scope for phase 1”. For example, I would think that many generics features would have an impact on the ABI, or the idea of COW (via secret boxing) for structs, or even union types.<br class="">
<br class="">
At the very least, I would think that mix-ins would have a fairly significant effect.</blockquote><div class=""><br class=""></div><div class="">ABI stability means that changes will have to be backwards compatible after a certain stage. If we can add mixins feature without modifying old code (and its SIL and IR and whatever), then we are fine. </div></div></div></div>
</div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>