ABI Stability Deferred Until After Swift 3.0
Erica Sadun quotes Chris Lattner:
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release [Swift 3.0] – including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the highest priority features to get done.
Compare the Swift-Evolution goals for Swift 3 to how they were before Chris changed them. They used to be Stable ABI; Resilience; Portability; type system clean up and documentation; complete generics; focus and refine the language; API design guidelines. Only two of those goals will be met – the last two.
Judged by its original goals, the Swift 3 release is a failure. Clearly we lost focus on what we were trying to achieve and we need to understand why. Unfortunately, Chris’s relocation of the goalposts is likely to obscure the fact of the failure and probably the same mistakes will be repeated for Swift 4.
I’m not worried because (a) I see a lot of the stuff that went into Swift 3 as more important than the stable ABI, and (b) I really want them to take the time to get Resilience right. ABI stability doesn’t affect app developers that much. The main issue is that it means you have to build from source, so you can’t include (Swift) libraries that were compiled by someone else, but I don’t see that as a common problem.
Update (2016-05-18): Greg Parker:
If we tried to rush Swift ABI stability out the door for Swift 3 we would certainly end up with deliberate or accidental flaws like the above. Being able to take the time to get it right is a rare luxury.
The move to Swift 3.0 isn’t just going to be disruptive. It’s going to be traumatic. With its expansive renamification and redesigned core types and APIs, Swift 3 is going to be a tidal wave of retraining and refactoring. And with a list of objectives that didn’t quite make the cut, and a laundry list of of items that should have, Swift 3 just doesn’t have enough time or scope to be perfected.
So why not just push it back? Let us devs use Swift 2.2, which is terrific, for a few more years and get Swift 3 right the first time?
[…]
These arbitrary “update every year” advances that Apple has bought into are more than a little ridiculous when it comes to firmware and OS updates; for languages it pushes beyond the practical.
This is why I thought it was good to get the major source-breaking changes into Swift 3 at the expense of ABI stability. However, it remains to be seen whether that goal can be reached on schedule.
Update (2016-05-23): Joe Groff:
A late ABI is only late until it’s finished; a bad ABI is bad forever.
So while ABI compatibility might seem like a big deal to have been pushed off, it very likely doesn’t affect the day to day of most Swift developers.
The most compelling arguments thus far have been around the fact that some developers would like to distribute libraries in binary form so as to protect intellectual property, license agreements, etc. Not having ABI compatibility is actually a legitimate concern for developers wishing to distribute binary libraries, but I don’t really feel like that’s a very large number of developers.
[…]
Which leads to the second major concern: that Swift compile times are a) slow, b) unlikely to get much faster and c) will only get slower as projects increase in size and complexity. Having some libraries built as binary libraries that are simply linked with additional Swift sources would likely result in much faster build and test cycles.
7 Comments RSS · Twitter
I’m not sure the link to Jeremy Pereira is correct. It links to Erica Sadun’s post.
"The main issue is that it means you have to build from source, so you can’t include (Swift) libraries that were compiled by someone else, but I don’t see that as a common problem."
• Doesn't this also make including the 12MB Swift payload mandatory for every single executable making Swift quite inconvenient to use to develop small executable (such as the ones running on servers or for background processes)?
• If you are the developer of your app, OK, it's not a big issue but if a company contracted someone to develop the app, doesn't this mean that the company needs to spend money … again?
As of today, choosing Swift as a language to develop an app may be a bad choice if you're not the developer of the app or you did not take into account the time you will spend adapting the code with each new release.
@somebody Yes, it does mean that you’ll still need to include the Swift libraries. In some cases they can be shared among related executables. But that’s been the case since 1.0, and I don’t see a lot of complaints about it. Unless you were only going to support the latest OS version, you would have to keep including the libraries, anyway.
I think the stuff that Swift 3 is focusing on actually means that we’ll see source stability sooner than if they had instead been focusing on the ABI. But, yes, I agree with the general point that it’s not a good choice if you don’t have someone to maintain and adapt the code.
