What a surprisingly exciting week! Discussions on Swift’s concurrency story (for Swift 5) have started with a new manifesto and proposal for async / await, and the new refactoring tools were open sourced with a blog post explaining how do implement your own refactoring actions. There’s a lot of exciting work ahead!

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

If you’re interested in contributing to Xcode 9’s brand new refactoring tools, here are a handful of tasks for implementing new refactoring actions.

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

Swift Unwrapped

Episode 25: ABI Stability — Calling Convention, Runtime and Standard Library. In the fourth and final episode in our series on ABI Stability, we cover the remaining categories of decisions that must be made to stabilize the ABI.

News and community

Xi Ge wrote an excellent post on the Swift.org blog, Swift Local Refactoring. The post not only describes how the refactoring tools work, but provides walk-throughs on how to implement new actions yourself!

Xcode 9 includes a brand new refactoring engine. It can transform code locally within a single Swift source file, or globally, such as renaming a method or property that occurs in multiple files and even different languages. The logic behind local refactorings is implemented entirely in the compiler and SourceKit, and is now open source in the swift repository. Therefore, any Swift enthusiast can contribute refactoring actions to the language. This post discusses how a simple refactoring can be implemented and surfaced in Xcode.

At this point, we all know that no major feature in Swift is worth discussing without a manifesto. Lucky for us, Chris Lattner wrote a concurrency manifesto this past week! Or, as he described: “An essay looking at how async/await+actors could transform Swift concurrency & distributed compute.” He emphasizes that this is only one possible approach, and details how the concurrency story in Swift could grow and evolve over many years. It’s only 19 pages! 😄 There’s also a much older concurrency doc in the Swift repo if you’re interested.

Brian Gesiak started a tutorial series on Swift compiler development with his inaugural post, Getting Started with Swift Compiler Development. This is a great introduction to making your first changes in the compiler.

John Holdsworth wrote a post on Swift in Android Apps, in which he lays out a brief history and the current state of Swift on Android. He explains the Swift Android toolchain, code generation, and communicating with the JNI. I’m not sure if this is worth the effort, but it is super interesting!

… a viable environment exists that opens the possibility that model, business logic and network code can be shared between Android and iOS when it is written in Swift.

From Slava Pestov:

Great collection of fast and slow type checker test cases to catch regressions and track progress. (Link)

The 2017 US LLVM Developers Meeting will be on October 18-19. The LLVM Foundation is also hosting its first Women in Compilers and Tools Reception, in conjunction with Developers Meeting. “This event aims to connect women in the LLVM community and the field of compilers and tools. It also is open to anyone (men or women) who is interested in increasing diversity within the LLVM community, their workplace or university.”

Xcode 9 beta 6 was released. (Release notes)

Commits and pull requests

Chris Lattner opened a pull request with a prototype for async / await.

Ben Langmuir added code completion for generic where clauses.

Kelvin Ma opened a pull request with an implementation for SE-0184: Improved pointers. However, it looks like this is going to require more discussion on the mailing list.

As previously discussed, Robert Widmann removed the SwiftExperimental library.

Proposals

Chris Lattner and Joe Groff drafted a proposal for async / await. This is still in the early stages, but it looks like this has a substantial chance of being included in Swift 5, despite the urgency of ABI stability. Prototype implementation here.

Mailing lists

Ted Kremenek kicked off concurrency discussions for Swift 5:

One of the goals for Swift 5 is to start laying the groundwork for a concurrency model. […]

Concurrency is a topic with many axes of design to explore, as the different domains we wish Swift to be successful will place different demands on a model. That exploration will take time: there will be tradeoffs with any model, and evaluating those tradeoffs will take discussion and iteration.

Today I’d like to open up swift-evolution to start some discussions about concurrency. Some of those discussions will focus on broader designs and concerns, and some will focus on specific use cases which we want to work great in Swift. Some opinions will likely differ significantly in the directions we should take — that’s fine. We intentionally want to explore different design spaces here, as a concurrency model for Swift has far reaching impact in the long-term on Swift as a language.

To kick things off, Chris Lattner has been sharing privately with a few people his own ideas for concurrency, which I have encouraged him to send out after this email. […]

Also of note, Ted briefly mentioned an update on the move to Discourse:

Once the Discourse forum comes online (which we are making progress on) we will likely tag or somehow segregate/mark discussions related to concurrency so they can easily be found. […]

Chris’s email introducing the concurrency manifesto:

As Ted mentioned in his email, it is great to finally kick off discussions for what concurrency should look like in Swift. This will surely be an epic multi-year journey, but it is more important to find the right design than to get there fast.

I’ve been advocating for a specific model involving async/await and actors for many years now. Handwaving only goes so far, so some folks asked me to write them down to make the discussion more helpful and concrete. While I hope these ideas help push the discussion on concurrency forward, this isn’t in any way meant to cut off other directions: in fact I hope it helps give proponents of other designs a model to follow: a discussion giving extensive rationale, combined with the long term story arc to show that the features fit together.

[…]

During the discussion on Chris’s concurrency manifesto, typed throws came up as a sub-discussion (which has been briefly discussed before on the mailing list).

Typed throws is something we need to settle one way or the other, and I agree it would be nice to do that in the Swift 5 cycle.

For the purposes of this sub-discussion, I think there are three kinds of code to think about:

1. large scale API like Cocoa which evolve (adding significant functionality) over the course of many years and can’t break clients.
2. the public API of shared swiftpm packages, whose lifecycle may rise and fall - being obsoleted and replaced by better packages if they encounter a design problem.
3. internal APIs and applications, which are easy to change because the implementations and clients of the APIs are owned by the same people.

These each have different sorts of concerns, and we hope that something can start out as #3 but work its way up the stack gracefully.

Continue reading…

Finally

And finally — this is too much for me to handle.