[swift-evolution] A case for postponing ABI stability

[Greg Parker]

> On Jan 27, 2017, at 2:57 AM, Charlie Monroe via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jan 27, 2017, at 11:35 AM, Tino Heth via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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?

That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.

The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale. 

(NeXT used framework versioning a few times, back when the entire OS only had a handful of frameworks. Today's AppKit and Foundation are version C. libSystem is version B. That's about it.)


>> Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that language did things that are worse ;-)

Note that Apple's OS frameworks do not export C++ interfaces. One reason was exactly that historically-unstable C++ ABI. Apple's OS developers chose #2 above for C++. OS frameworks and apps could get away with mismatched C++ ABI because they don't pass C++ objects to each other.


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler


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