Welcome back to the weekly! I took a much needed break last week, so I’ll try to report on the last two weeks today. As always, if I missed anything, send a pull request!

Xcode 8 beta 6 was released this week. It’s a huge update from the previous beta, containing a number of completed swift-evolution proposals.

Generally speaking, it looks like the Core Team is still in the process of fixing, refining, and finishing Swift 3. There’s little to no activity on GitHub or the mailing lists about Swift 4 yet — aside from Chris Lattner’s original email and some initial minor discussions. In fact, if you look at the swift-evolution archives since Ted Kremenek’s “end of Swift 3” announcement, the past few weeks have had substantially fewer messages than previous weeks — roughly 100-300 instead of 500-1,000 messages.

I’m definitely looking forward to a calmer Swift development cycle that focuses more on stability and reducing churn for users — and so far it seems like Swift 4 will do just that! 😄

Starter tasks

  • SR-2354: [Compiler] inout parameter in subscript gives the wrong error message
  • SR-2145: [Compiler] Incorrect fix-it application when correcting optionals as booleans in a ternary in a lazy-var initializer
  • SR-2083: [SwiftPM] Don’t error if a directory contains only ignored files

Submit a task by sending a pull request or opening an issue.

Commits and pull requests

Paul Meng merged changes to swift/sema to continue the work on SE-0110.

Daniel Dunbar implemented proposal SE-0135. (See below)

Jordan Rose fixed an issue to allow Any as an IBAction’s sender and an IBOutlet’s type.

Joe Groff fixed a SILGen and IRGen bug that caused crashes and linker errors when Objective-C generic classes conformed to Swift protocols.

Accepted proposals

SE-0135: Package Manager Support for Differentiating Packages by Swift version by Anders Bertelrud was accepted.

There was little feedback on the proposal, in particular relative to the complexity of the proposal and space of possible things we could do. We found this unfortunate, but are still accepting the proposal for the following reasons:

  1. Since we cannot anticipate in advance how widely or for how long the Swift 3.0 package manager will be used, we feel it is important to have some escape hatch for Swift/SwiftPM version specific dependency selection.
  2. The proposal is purely additive and intended to only be a short term mechanism. If it turns out to never be needed, or not suffice for the purpose for which it was designed, then we can remove it in a future release with little overhead.

SE-0137: Avoiding Lock-In to Legacy Protocol Designs by Dave Abrahams and Dmitri Gribenko was reviewed and accepted.

Community feedback to this proposal was light but positive. The core team agrees that the proposal is a reasonable change to make for Swift 3, even at this late date. Thanks go to Dave Abrahams for pushing to get this into the release.

SE-0137 Proposal summary:

We propose to deprecate or move protocols that shouldn’t be a part of the standard library’s public API going forward.

We’ve always known that when Swift reached ABI stability (now slated for Swift 4), we would be committed to supporting many of the standard library’s design decisions for years to come.

We only realized very recently that, although Swift 3.0 is not shipping with a stable ABI, the promise that Swift 3.0 code will work with Swift 4.0 means that many of the standard library’s protocols will be locked down now. Especially where these protocols show up in refinement hierarchies, we won’t be able to keep Swift 3 code working in the future without carrying them forward into future standard library binaries.

Mailing lists

Ivan Akulov announced that they have translated The Swift Programming Language book into Russian! There’s also a repo on GitHub where you can report issues. 😎

On the LLVM-dev list, Doug Gregor announced a job opening for a Swift frontend compiler engineer. 🤓

Finally

And finally — what were your #FirstSevenLanguages? 😂