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:


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


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:


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:


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 

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
swift-evolution mailing list

Reply via email to