[swift-evolution] A case for postponing ABI stability

[Ted kremenek]

Hi David,

My apologies for being late to the thread — I've been away for the last week.

ABI stability remains a keystone goal for Swift, but the concerns you have here about not rushing important things are real.  There's been a lot of scoping work into what ABI stability means, soup-to-nuts from the runtime to the Standard Library.  As Michael Ilseman said he plans on sending out a manifesto shortly (possibly today) that includes a bunch of the scoping information for ABI stability.  We also plan on having a dashboard up (probably on swift.org) that will allow the community to get a holistic view of the work on ABI stability and see the progress being made toward that goal.  With that information we (the entire community) can make informed decisions on the priorities of specific ABI stability tasks and for Swift in general, and the relative tradeoffs being made.  As Joe Groff said elsewhere in this thread some aspects of ABI are additive, and thus can be added later.  When scoping ABI stability, we are trying to assess those kinds of lateral tradeoffs.

But as you point out, a lot of decisions get locked in once we have ABI stability.  As part of that, we'll have some public discussion soon on when to open up "phase 2" (per Chris's email over the summer about goals for Swift 4) and what it means for Swift 4.  I think a key goal for "phase 2" is to front load important design changes to Swift that may have implications on ABI.

Thank you for bringing up this topic.  Let's continue this general discussion about ABI stability and what it means for prioritizing specific tasks for Swift once Michael has his manifesto out.

Ted

> On Jan 23, 2017, at 10:40 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello swift-evolution,
> 
> ABI stability is an important feature which many Swift users are looking forward to. If I understand it correctly, once it’s here, the Standard Library becomes part of that ABI and only additive and backwards-compatible changes can be done. Seeing how we are still heavily modifying the Standard Library this year (Strings), wouldn’t it be wiser to let those changes simmer under the scrutiny of the broader community of Swift users for a year before we make it into the ABI?
> 
> ABI compatibility is important. Some projects need it, but I think that most projects (most Apple platform third-party applications) would only mildly benefit from it. But I want to make sure the Standard Library has had enough time to mature before we set it in stone.
> 
> Regards,
> David.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution