I recently spoke at the FrenchKit conference about Swift Evolution. The talk, 140 proposals in 30 minutes, was originally intended to be an overview of the process and each of the proposals. However, as I was writing the talk, it evolved into something much more interesting. I ended up writing some code to analyze the proposals instead.
All of the proposals are publicly available on GitHub, but they are just markdown files — plain text. Because of this, there isn’t an easy or efficient way to query or filter them. We can’t filter them based on author. We can’t group them by the Swift version in which they were implemented. We can’t query their contents. And on and on…
Now we can do all of these things, and more — interactively via Swift playgrounds.
The swift-proposal-analyzer project repository contains a number of components. (Everything is written in Swift, of course.) I’ll refer you to the README for details, but here’s the basic flow for how everything works:
- It syncs/fetches the proposals from the main apple/swift-evolution repo
- It does some processing and parsing of the proposals
- You end up with a playground that lets you interact with the proposals
- The playground contains all of the proposals as raw resource files, as well as playground pages
In the playground, you are presented with an array of
Proposal objects, which contain most of the proposal metadata, as well as the raw file contents.
Proposal has a title and SE number, an array of
Author objects (1 or more), a
Status, a filename, the file contents, and the total (rough) word count.
Author only contains the author’s name.
Status of a proposal is defined as an
We’ve gone from a directory of plain text files to structured data that we can query and filter. 😎
Here are a few brief examples to show what kinds of questions we can ask and answer.
Querying the data
These examples show very basic queries, but we can build upon these to derive much more sophisticated data describing how proposals vary over time. For example, we could plot an author’s influence over time. Is she writing fewer or more proposals for each version of Swift? Or, how is Swift itself evolving over time? Does each version of Swift include more or fewer proposals than the previous one? At what rate are proposals increasing or decreasing?
Since this is such a targeted set of data, we can use word count as a rough metric for complexity, i.e. the longer a proposal is, the more likely it is to be a larger, more complex change. For example, SE-0107: UnsafeRawPointer API comes in at around 7,300 words, while SE-0114: Updating Buffer “Value” Names to “Header” Names is only about 167 words. The latter is simply a renaming, while the former made significant changes to the lower-level
UnsafePointer APIs. How does the complexity of proposals vary over time?
I haven’t had time to dive this deeply into Swift Evolution, but maybe someone from the community will. Swift is only about 2 years old, so we probably can’t conclude that much yet. In any case, it’s fun to play around with the data.
Of course, my talk is already out-dated and it will be a few more weeks until the videos are available. 😂 I guess the Swift Evolution process is just as fast as Swift itself. And now this article has turned so meta I can’t even. 😄
Here are some interesting things about Swift Evolution that the status page can’t tell you:
- 75% of all proposals have been accepted. 70% of these have been implemented.
- Swift 2.2 to Swift 3.0 saw a 1,012% increase in proposals.
- There are 79 unique authors.
- Most proposals have 1 or 2 authors, but there’s one that has 9 authors.
- Erica Sadun has authored or co-authored more proposals than anyone, including everyone on the Core Team.
The following are the top 10 authors, and the number of proposals that they have written or co-written. Note that half of them do not work at Apple (that I know of, at least). These individuals were certainly influential in Swift 3.
- Erica Sadun, 25
- Doug Gregor, 15
- Joe Groff, 12
- Dave Abrahams, 10
- Chris Lattner, 10
- Dmitri Gribenko, 7
- Jacob Bandes-Storch, 6
- David Hart, 6
- Austin Zheng, 5
- Kevin Ballard, 5
Contributing to Swift isn’t just about writing compiler code. It’s also about ideas. You don’t have to be a compiler expert to have ideas. And you don’t need to write C++ to have an influence on Swift. All you need is a great idea to make the language better for everyone.
Like I mentioned above, Swift is still young — and our dataset of proposals is quite small. We should be cautious with any conclusions, but there’s a lot here to think about and a lot more we can learn! Send me a pull request, there’s plenty to work on! 😄