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.

Community

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!

Brian Gesiak wrote a blog post on Contributing to Nuclide’s Swift Integration: Why and How. If you want to help make Nuclide a viable editor for Swift, then read on!

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!

Proposal status

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 prefix(while:) and drop(while:) to the stdlib
  • SE-0068: Expanding Swift Self to 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

SE-0135: Package Manager Support for Differentiating Packages by Swift version by Anders Bertelrud is under 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 #if directives 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.

Mailing lists

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.

continue reading…

Finally

And finally — have you seen this painting of Jonathan Swift holding the first *.swift file? 😄 I wonder if he ever wrote any proposals. 😉