[swift-evolution] Swift 5: start your engines

[Ted Kremenek]

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is now in endgame engineering convergence for an expected release later this year.  Swift 4 has turned out to be one of the highest quality, well-rounded releases of Swift, and I am grateful to everyone in the community who made this release come together!

Now it is time to turn our attention to Swift 5.  I have just posted updates to the README.md file on the swift-evolution repository, which outlines the core themes and focus areas for Swift 5:

  https://github.com/apple/swift-evolution <https://github.com/apple/swift-evolution>

and a more persistent URL (invariant to future README.md changes):

  https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md <https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md>

I am not going to repeat all of that information here, but I wanted to highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it.  With Swift 4, ABI stability was a strong goal.  In Swift 5, it is a *requirement* of the release.  Whatever ABI we have at the end of Swift 5 is the ABI that we will have.  ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module stability.   If you are not aware of the difference — which is rather important — please read the first few paragraphs of the ABI stability manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md <https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md>

Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.

##  Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat here, but there is a general theme of refining and broadening out the core ergonomics of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for concurrency.  It is a non-goal of Swift 5 to roll out a full new concurrency model.  That is simply too large an effort to do alongside ABI stability.  However, it is important that we start making progress on discussing the directions for concurrency and laying some of the groundwork.  This may take the form of specific enhancements to the language that get implemented, depending on where the discussions for concurrency lead and how they align with the priorities for delivering ABI stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  https://github.com/apple/swift-evolution <https://github.com/apple/swift-evolution>#evolution-process-for-swift-5 <https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5>

With Swift 4, the release period was divided up into “stage 1” and “stage 2” for setting guidelines for the kind of evolution proposals that were in scope for the release.  This was needed to establish focus — especially after the churn we saw during Swift 3 — on some core themes that were aligned with converging the language towards source & ABI stability.  One downside is that “stage 2” opened up discussion for potentially disruptive changes fairly late in the release.  Further, some proposals — such as SE-0155 — came in so late that there was little runway to actually implement them for Swift 4, let alone evaluate their impact in practice on real projects.  Related, there has been some desire  for a while to be able to better evaluate the impact of proposals on real code before they are locked into the release, and the best way to do that is to actually have an implementation that vets out the design in a proposal.

With Swift 5, the focus on ABI stability will predominate priorities for both design and implementation work, but the Core Team did not want that focus to stifle all discussion on potential enhancements to the language that were not fundamentally tied to that primary goal.  After reflecting on the evolution process during both the Swift 3 and Swift 4 releases, the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by **requiring that all proposals have an implementation** before they are officially reviewed by the Core Team.  An implementation can come long after an idea has been pitched and after a proposal has been written.  However, before a pull request for an evolution proposal will be accepted — and thus an official review scheduled — an implementation must be in hand for a proposal as part of the review.  The existence of an implementation does not guarantee that the proposal will be accepted, but it is instrumental in evaluating the quality and impact of the proposal.

There are two key benefits of requiring an implementation:

1. It encourages a design in a proposal to be more thoroughly fleshed out before the proposal is formally reviewed.  The hope is that this will make the review process both more efficient as well as more effective.

2. An implementation allows the proposal to be evaluated on real world code and not just the examples that are in the proposal.

The Core Team is also sensitive to proposal authors investing time in providing an implementation for a proposal that is not likely to get traction.  The Core Team will be regularly reviewing potential proposals, and provide feedback either during the pitch stage or when a proposal is submitted via a pull request on whether or not the proposed change looks within the charter of the release or meets the criteria for a valuable change to the language.

Requiring an implementation naturally raises the bar for proposals.  While this is by design, it can possibly have the negative aspect of making some feel the bar is too high for them to participate in the Swift evolution process.  As an open source project, both the design and implementation of the language is a highly social endeavor, and we encourage the community to collaborate on both the design and implementation of proposals.  Specifically, it is not a requirement that the original author(s) of a proposal be the one who provides an implementation — all that matters is that there is an implementation when a proposal gets reviewed.

Lastly, an important aspect is that unlike Swift 4, the broadening of scope for proposals considered for Swift 5 begins… now!  Proposals that fit within the general focus of the release are welcome until March 1, 2018. Proposals will still be considered after that, but the bar will be increasingly high to accept changes for Swift 5.

- Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170808/ace88183/attachment.html>