With Swift 4 development wrapping up, this week the goals for Swift 5 were announced! There are a lot of things to unpack in this announcement, but two main topics stand out — ABI stability and changes to the Swift Evolution process.
First, ABI stability is not merely a goal for Swift 5, but a requirement for the release. Notably, this is the first Swift release to have a hard requirement like this. As Ted discussed in the email, whatever ABI we have at the end of Swift 5, that’s what we’re stuck with! So there you have it, no more ABI stability delays! This likely means that iOS 12 could be the first release to ship with Swift, no longer requiring application developers to bundle the Swift runtime and standard library with their apps.
Secondly, the Swift Evolution process will see substantial changes. If you recall, the Swift 4 development cycle was split up into two “phases” in an attempt to address the somewhat chaotic churn of proposals that we saw during the development of Swift 3. The intent of Swift 4’s phases was to keep the release focused on meeting its goals, but this didn’t quite work out as expected. Thus, beginning with Swift 5 proposals are required to have an implementation before being officially reviewed by the Core Team.
There’s some concern in the community that this raises the bar too high for proposals and participation will decrease dramatically as a result. However, this new rule does not mean that the proposal author is required to implement the changes. It only specifies that an implementation must be available in order to be reviewed. Thus, multiple contributors can collaborate on writing and implementing. Despite the potential downsides, I’m in favor of this change. I expect it reduce much of the distraction and pure bikeshedding that happens sometimes on the mailing lists. And practically speaking, I honestly don’t see any other option given the importance of ABI stability — have you seen how much work is still left to do? 😅 Another benefit of this is that we could see the actual impact of the proposal on real-world code and include that as part of the review process. This will hopefully avoid another debacle like the access control controversy of Swift 3.
Start your engines! 🏎