[swift-evolution] A case for postponing ABI stability

[Greg Parker]

> On Jan 27, 2017, at 9:19 AM, Tino Heth <2th at gmx.de> wrote:
> 
>> It would mean for Apple (and others who'd distribute compiled frameworks) to maintain several code bases of the same framework given that they would need to maintain backward compatibility and hence wouldn't be able to use new language features, etc. It's IMHO not that much about the technical constraint of having multiple binaries within the framework bundle as much as maintaining the code in a way that would compile under all Swift versions you'd like to support.
> 
> I haven't spend much time thinking about the implications, but wouldn't it be feasible to freeze old frameworks completely when a new Swift version is added?
> After all, bundled code isn't updated at all, so I see no downside here — actually, it only adds flexibility that could be utilised when critical bugs are discovered.

You can't simply freeze an old version of a framework. Many app frameworks have interfaces with other OS components. Freezing the app side of the interface also constrains the other side, effectively introducing another piece of ABI that must be kept stable.

For example, CoreGraphics needs to talk to the window server. If you try to freeze some version of CoreGraphics then you require the window server to implement that particular interface forever. Now the window server's private interface has become an ABI that must preserve binary compatibility. The same is true for the spellcheck server, the pasteboard server, the address book database server, and a great many others.


-- 
Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170127/8c17eb02/attachment.html>