[swift-evolution] A case for postponing ABI stability

[Michael Ilseman]

> On Jan 24, 2017, at 12:12 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Imho the major problem is that there's quite a lot confusion about what ABI stability actually means — and a lot uncertainty which proposals would actually affect it.

I’m hoping to clarify this very soon with a lot more information.

> People with more insight may prove me wrong, but I'll lay out my understanding in the next paragraph:
> It shouldn't be hard to have several versions of the stdlib installed, and no one talks about API stability (which is great as well — but a superior API imho is better ;-)
> ABI is very low level and affects the junction of software and hardware (which bits are put into which location when a function call happens, utilisation of registers…).
> 

While ABI is low-level, at least in the sense that binary interfaces are low-level, a language’s ABI is actually pretty cross-cutting. All of a languages features and semantics that may be exposed across ABI boundaries need a place in the languages ABI, and Swift has a lot of features.

> I'm not really sure if the String-changes affect the ABI, but none the less, I strongly agree with your opinion that things shouldn't be done in a hurry, and I hope that Swift keeps the courage to break things for the better (sporadically ;-)
> 

One subtlety that’s not always brought up is that when we talk about stabilizing the Swift ABI, what is really important is stabilizing the interface of libSwiftCore. libSwiftCore includes the standard library and language runtime, so in a hand-wavy sense the stdlib’s API is part of libSwiftCore's ABI. Again, much more on this soon.


> - Tino
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution