Back in July, we laid out a plan for Swift 4 which divided the release into two
stages. Since then, we’ve been in Swift 4 stage 1, which is characterized by
the following text in the swift-evolutionrepository's README.md
<https://github.com/apple/swift-evolution/blob/master/README.md#development-major-version--swift-40>
file as follows:
Stage 1 focuses on the essentials required for source and ABI stability.
Features that don't fundamentally change the ABI of existing language features
or imply an ABI-breaking change to the standard library will not be considered
in this stage. Swift 4 is currently only considering proposals that fit in
Stage 1.
Stage 2 will commence once the implementation work on the Stage 1 features is
cresting, and can contain a few other large and small features. We expect that
stage 2 will commence some time in Spring 2017.
Since July, we now have a much better understanding now of how to achieve ABI
stability, with an ABI Manifesto
<https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md>
detailing the list of all language/implementation work that is needed to
achieve ABI stability. We have made substantial progress in that work during
stage 1, but much remains to be done. Once Swift achieves ABI stability the ABI
can be extended, but not changed. Thus the cost of locking down an ABI too
early is quite high.
Deferring ABI Stability from Swift 4
Given the importance of getting the core ABI and the related fundamentals
correct, we are going to defer the declaration of ABI stability out of Swift 4
while still focusing the majority of effort to get to the point where the ABI
can be declared stable.
To allow the community to follow along with this effort, an ABI dashboard will
get wired up from the swift-evolution
<https://github.com/apple/swift-evolution> home page that will present a table
of main ABI tasks remaining and what Swift release they landed in. This
dashboard will largely track open tasks in JIRA. I expect the dashboard to be
up next week, and I'll send a follow up email when it is available.
Stage 2
With ABI stability well-understood and many of the stage 1 goals underway, it
is time to open up Swift 4 stage 2 to expand the scope of proposals to be
considered.
Timeline
Stage 2 starts right now. All design work and discussion for stage 2 extends
to April 1, 2017. The intent is to timebox discussion to provide adequate time
for the actual implementation of accepted proposals.
Scope
Swift 4 stage 2 builds on the goals of stage 1. It differs in that stage 2
proposals may include some additive changes and changes to existing features
that don't affect the ABI. There are a few focus areas for Swift 4 stage 2:
Stage 1 proposals: Any proposal that would have been eligible for stage 1 is a
priority for stage 2.
Source-breaking changes: The Swift 4 compiler will provide a
source-compatibility mode to allow existing Swift 3 sources to compile, but
source-breaking changes can manifest in "Swift 4" mode. That said, changes to
fundamental parts of Swift's syntax or standard library APIs that breaks source
code are better front-loaded into Swift 4 than delayed until later releases.
Relative to Swift 3, the bar for such changes is significantly higher:
The existing syntax/API being changed must be actively harmful.
The new syntax/API must clearly be better and not conflict with existing Swift
syntax.
There must be a reasonably automatable migration path for existing code.
Improvements to existing Standard Library facilities: Additive changes that
improve existing standard library facilities can be considered. With standard
library additions in particular, proposals that provide corresponding
implementations are preferred. Potential focus areas for improvement include
collections (e.g., new collection algorithms) and improvements to the
ergonomics of Dictionary.
Foundation improvements: We anticipate proposing some targeted improvements to
Foundation API to continue the goal of making the Cocoa SDK work seamlessly in
Swift. Details on the specific goals will be provided as we get started on
Swift 4 stage 2.
As part of initiating Swift 4 stage 2, the Core Team reviewed those proposals
that were accepted into Swift 3 but were never implemented:
SE-0104 "Protocol-oriented Integers": This proposal requires revision and
another round of review based on other changes that have been made to the
language and standard library since acceptance.
SE-0075 "Adding a Build Configuration Import Test": This is (still) an additive
proposal and no other changes affect this proposal. It will be carried forward
and considered accepted for Swift 4.
SE-0042 "Flattening the function type of unapplied method references”: This
proposal requires another round of review. This is a significant
source-breaking change, and the bar for such source-breaking changes is
considerably higher in Swift 4 than it was in Swift 3.
SE-0068 "Expanding Swift Self to class members and value types": This is
(still) an additive proposal and no other changes affect this proposal. It will
be carried forward and considered accepted for Swift 4.
The Core Team has also identified some starter proposals
<https://bugs.swift.org/browse/SR-3316?jql=labels%20%3D%20StarterProposal> that
fit well with the goals of Swift 4. Taking one of those ideas and developing it
into a complete proposal is a fantastic way to get involved in the Swift
evolution process.
Ted
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
