> On Jan 27, 2017, at 9:19 AM, Tino Heth <[email protected]> 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 [email protected] <mailto:[email protected]> Runtime Wrangler
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
