> On Jan 27, 2017, at 11:35 AM, Tino Heth via swift-evolution > <swift-evolution@swift.org> wrote: > > >> I don’t disagree with your overall point, but I do want to emphasize that >> forcing apps to bundle the stdlib and runtime is more than just suboptimal. > > Wouldn't it be possible to have several versions of the runtime bundled with > the OS? Frameworks on macOS still have a filesystem layout that is build > around the idea of having several versions in one bundle.
I have personally thought about this as well, but it would also mean that the OS frameworks would need to come in several versions - imagine the following scenario: Swift 4 libraries are included with macOS 10.13, some frameworks in the system link against them (e.g. AppKit). Then, with macOS 10.14, Swift 5 comes along with ABI incompatible changes. AFAICT, if you want apps written compiled with Swift 4 to work under 10.14, you'll need: - runtime libraries for Swift 4 - all system frameworks will need to contain two variants - one compatible with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in the long run. For how long would you need to keep several versions of the framework around? What happens when Swift 6 comes along with another breaking changes? Would each system framework have 3 versions embedded? > > Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that > language did things that are worse ;-) > > I guess the problem is at least partly a phycological one: > ABI stability was supposed to be one major feature of Swift 3, and it's > somewhat depressing when big goals are delayed over and over. > > Maybe you could "stabilise" the ABI temporarily, and plan for a breaking > change in two or three years, when the dust has settled? > Doing so would reduce the pressure, and long-term Mac developers are used to > huge breaking changes anyway ;-) > It could also free resources to work on features and ideas that help to > realise shortcomings worth to be addressed in a "really stable" ABI. > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
