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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
