> On Aug 11, 2016, at 1:57 PM, Slava Pestov via swift-evolution > <swift-evolution@swift.org> wrote: >> 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 > > 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.
I think perhaps the other thing that might matter here is that we can always add to the ABI in backwards-compatible ways. So, for instance, we don't have to nail down all generics features immediately just because they affect the ABI; we just need to nail down the ABIs of existing features, plus any new features which will change the design of existing standard library features. If we ever add, say, higher-kinded types, they will certainly have some kind of representation in the ABI, but as long as they don't affect the binary representation of non-higher-kinded types, that won't really affect compatibility with existing code. Similarly, there's a straightforward way to implement COWed structs in a backwards compatible way: treat them as a struct wrapping a reference to an object containing the data. As long as the compiler implements COWed structs in that fashion, or in any other way that's expressible in the existing ABI, COW structs are only an issue if we redesign inlineable parts of the standard library to use them. (Correct me if I'm wrong, because I might be, but that's the impression I have.) -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
