Swift ABI Stability Delayed Again
Since July, we now have a much better understanding now of how to achieve ABI stability, with an ABI Manifesto detailing the list of all language/implementation work that is needed to achieve ABI stability. We have made substantial progress in that work during stage 1, but much remains to be done. Once Swift achieves ABI stability the ABI can be extended, but not changed. Thus the cost of locking down an ABI too early is quite high.
Given the importance of getting the core ABI and the related fundamentals correct, we are going to defer the declaration of ABI stability out of Swift 4 while still focusing the majority of effort to get to the point where the ABI can be declared stable.
In practical terms, there are very few advantages to Swift achieving ABI stability. The primary benefit is that it would allow Apple to ship Swift frameworks on its operating systems, rather than ones written in Objective-C. It would also reduce Swift compiled application size by a few megabytes as apps would no longer have to include copies of the compiled standard library.
In the scheme of things, these benefits are not critical to reap. The scope of Swift project is far wider than that. Improvements to compiler bugginess, optimisation and language feature development help a much bigger audience. Thinking egotistically as as a solo (indie/contract) developer, those changes mean everything and ABI stability means nothing.
Hence, I am not upset that ABI stability will not be achieved this year. I am disappointed that the Swift project is once again deferring a milestone goal, the same goal in fact. In the Swift 3.0 planning stages, ABI stability was touted as a headline change. A few months in, the core team pronounced it was too early and became a leading Swift 4 priority.
In fact, the Swift 4 open-source development structure was purposefully split into two phases, devised specifically to focus solely on ABI stability matters in the first phase. Phase one is now over, yet ABI stability is still nowhere close to being achieved, although there are now more formal plans about what needs doing. The reasons given for delaying it this time is that it would take too much time to implement the plans (and there are still several ABI-affecting things that need to be designed).
I would argue it was obvious from the outset that there was never going to be enough time in this development cycle to do it and that freezing ABI prematurely would be damaging. The fiasco is a prime example of project mismanagement that ultimately distracted everyone involved from achieving other meaningful, feasible features. The idea of achieving ABI stability should never have been on the table for Swift 4, let alone Swift 3. I hope that the next time ABI stability is brought up on Swift Evolution, it is appropriately timed.
That being said, with the course correction now in place, I look forward to everyone focusing on things which I deem important and useful for improving Swift, like completing the generics system (which was also deferred from Swift 3, for what it’s worth).