> On Aug 11, 2016, at 1:48 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Aug 11, 2016, at 4:27 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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: > > https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst > <https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst> As a follow-up explanation, when we talk about the ABI, we're really talking about three orthogonal "axes" along which we would like to "move" without breaking compatibility with existing binaries:
- The first axis is the machine-level calling conventions and memory layout. For example, what registers to pass function arguments and returns in, the rules for alignment and padding of fields in an aggregate type, which entry points the Swift runtime exports and what their behavior should be. Once we commit to a stable ABI along this axis, you will get interoperability between *compiler versions* -- the same exact library built with one version of the compiler will remain compatible with clients after being recompiled with another version, because their conventions will match up. Note that this does not help you if the library itself changes in any way. - The second axis is the resilience work I called out in my previous e-mail. Here, we're trying to define language features and implementation techniques that allow a library to evolve in a forward-compatible manner, as long as the developer follows certain guidelines. Here, the goal is if you should be able to compile your library, make some changes to add new APIs, and recompile it *with the same compiler*, without breaking downstream clients, as long as you follow the library evolution guidelines (Also, you can imagine one day having an 'ABI diff' tool to automate this). - The third axis is the standard library itself. Stability of runtime interfaces and the extra indirection to enable resilience is all great, but it won't help you as long as the standard library API is evolving in a non-backwards compatible manner -- for example, if we remove a method on String. So once the other two areas have been addressed, the last thing to lock down is the standard library interface itself. > >> >> On 11 Aug 2016, at 13:24, Anton Zhilin via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> 2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
