About a week ago, Swift Core Team member Ben Cohen wrote a thoughtful message on swift-evolution, answering a question about the chances of purely additive proposals to be accepted for Swift 4.

Ben explains the rationale the Core Team uses to decide which proposals should make it into the next version of the language. The gist of it is that each Swift release should focus on a small number of themes and that proposals contributing to these themes will be given priority.

I think that post hasn’t received the attention it deserves, which is why I’m quoting it here in its entirety (links and emphasis added by me):

It’s worth noting that some additive proposals are currently in scope, where they are aligned with the themes set out for Swift 4. For example, additive proposals for String, Dictionary and Sequence/Collection are being accepted for the standard library. In upcoming releases of Swift, it is likely that additive proposals aligned with other themes, such as further string work (like native regexes), move-only types, concurrency, reflection, or further generics enhancements, will be in scope. We feel that keeping the focus on specific themes is really important for the evolution of the language, and that unconstrained additive proposals not associated with any current theme are always going to have a very high bar for acceptance.

One reason is bandwidth, both of the core team and of the community. Keeping the discussion focused on themes helps other community participants follow the mailing list (though hopefully a move to a message board format will help with this some). And by ensuring proposals are themed with the overall goals of each release, we stand a higher chance of avoiding a build-up of proposals that are accepted, but then not actually implemented.

Moreover, when discussions are focused on specific themes, we can provide a more complete, coherent design for the features within that theme. We can explore how (say) all of the new generics features of Swift 4 fit together to provide a complete, coherent system that is easier to use and explain, or how all of the new string features fit together to make Awesome Strings. It’s partly about messaging—what does Swift 4 bring to the table?—and partly about giving us a better chance at building a coherent design.

The coherent design is important both within the release—because it makes it easier for developers to learn to use the new features together—but also for the long-term health of the language. Without theming proposals, it is very difficult to see how an individual proposal fits into the overall direction of Swift. We would run the risk of making small local changes that we later regret when considering wider-reaching changes to which they are related. There is also a risk of not noticing the accretion of too many keywords or concepts in the language that individually make sense but overall don’t fit well together.

For example, recent proposals around refactoring of meta types really need to be considered in the wider context of reflection as a whole so should probably wait until that theme is in scope. Another example: the recent proposal SE-154 to change the types for the keys and values collections on Dictionary did not really make sense in isolation—it still only provided a slightly clunky way to solve the problem where dictionaries need an “initial” value, and then update that value in-place. But it needed to be considered as part of the ABI stability theme. It was partly for this reason we decided to open up a wider discussion of Dictionary for stage 2.

For Swift 3 and Swift 4, the core team set out the themes for each release. The core team would like to involve the community earlier in the process to help define the themes for future releases, but are still thinking about the best way to do so.

Swift 4.0 is still half a year away, but it’s never too soon to start speculating what the themes of Swift 5 will be. Surely ABI stability, but what else? More string refinements? Concurrency? Reflection?