What a week it’s been! Last week there were 23 accepted proposals that were “awaiting implementation”. Now only 8 remain! It’s incredible how much contributors from the community and the Core Team managed to accomplish in such a short time. The fourth beta of Xcode 8 was also released this week.
Russ Bishop gave a great talk titled Contributing to Swift: From Proposal to Shipped. Definitely check it out if you are interested in getting involved with swift-evolution!
Commits and pull requests
Han Sangjin started an initial port of corelibs-foundation to Cygwin.
As mentioned above, it was a big week for getting the final proposals for Swift 3 finished!
- Xiaodi Wu implemented SE-0134.
- Anders Bertelrud implemented SE-0129.
- Jacob Bandes-Storch implemented SE-0133.
- Doug Gregor implemented SE-0111.
- Robert Widmann finished implementing SE-0089.
- Michael Ilseman implemented SE-0103.
- Rintaro Ishizaki implemented SE-0101.
- Richard Wei and Robert Widmann implemented SE-0096.
- John McCall implemented SE-0117.
The proposals for Swift 3 that were accepted, but not implemented are:
- SE-0042: Flattening the function type of unapplied method references
- SE-0045: Add
drop(while:)to the stdlib
- SE-0068: Expanding Swift
Selfto class members and value types
- SE-0075: Adding a Build Configuration Import Test
- SE-0080: Failable Numeric Conversion Initializers
- SE-0082: Package Manager Editable Packages
- SE-0104: Protocol-oriented integers
- SE-0110: Distinguish between single-tuple and multiple-argument function types
It’s still not clear what is going to happen to these. Some are additive, so they could be implemented at any time. However, others contain source-breaking changes. There hasn’t been any communication from the Core Team on the fate of accepted-but-unimplemented proposals for Swift 3. I hope these make it into a Swift 3.x release, but it seems they may not be revisited until Swift 4.0 or later.
Proposals in review
As new, source-incompatible versions of Swift come into use, there is a growing need for packages to be authored in a way that makes them usable from multiple versions of Swift. While package authors want to adopt new Swift versions as soon as possible, they also need to support their existing clients.
Source incompatibilities can arise not only from changes to the language syntax, but also from changes to the Swift Standard Library and the Package Description API of the Swift Package Manager itself.
Support for multiple Swift versions could in theory be implemented using
#ifdirectives in the package source code, but that approach can become unwieldy when the required code differences are significant.
The Swift Package Manager should therefore provide facilities that make it as easy as possible for package authors to support clients using different versions of Swift. The proposal described here intends to solve an immediate need for Swift Package Manager 3; the need for version-specific packages will hopefully diminish as the language and libraries stabilize. We can revisit the need for this support in a future version of Swift.
Looking back on Swift 3 and ahead to Swift 4, from Chris Lattner:
The Swift 3 release is nearing completion, so it is time to look back on the release, learn from what happened, and use it to shape what we (the Swift community) do in the year ahead. Overall, Swift 3 is going to be an absolutely amazing release, and it is impressive how much got done. Thank you to everyone who contributed to making it happen. Instead of diving into a flurry of new proposals immediately, it is important to take stock of where we are, and look at the bigger picture.
Metapoint: this email is ridiculously long and covers multiple topics. Instead of replying to it directly, it is best to start new threads on individual topics that you’d like to discuss. Just tag them with “[Swift 4]” in the subject line.
And finally — have you seen this painting of Jonathan Swift holding the first *.swift file? 😄 I wonder if he ever wrote any proposals. 😉