[swift-evolution] ABI in Layman's terms?

Slava Pestov spestov at apple.com
Thu Aug 11 15:48:39 CDT 2016

> On Aug 11, 2016, at 4:27 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> I'd also like to understand this more and this answer does not completely satisfy me. I understand backwards compatibility, especially in terms of source breaking changes.
> I have more difficulties understanding what breaks or not the ABI and how to make educated guesses about what features will require breaking it

This is hard to explain right now without detailed knowledge of IRGen and SILGen internals. However we are planning on relaxing the restrictions as much as possible, so that source-compatible changes remain binary compatible. For example, we would like to be able to add new fields to structs, change computed properties to stored and vice versa, insert new classes in a hierarchy, add cases to enums, and so on. This falls under the umbrella of "resilience".

Here's a document outlining what will be ABI compatible and what will not -- keep in mind that a good chunk of this is not yet implemented:


> On 11 Aug 2016, at 13:24, Anton Zhilin via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> Could someone explain in simple terms what the ABI is and what sorts of things might affect it?
>> 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.
>> At the very least, I would think that mix-ins would have a fairly significant effect.
>> 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. 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160811/2549242e/attachment.html>

More information about the swift-evolution mailing list