What a week for Swift! Swift 3.0.1 is here, but what’s more exciting is the new Server APIs Work Group and Server APIs Project from Swift.org! See below for details. The Xcode 8.1 GM seed was released, which bundles Swift 3.0.1. There are a number of improvements in Swift 3.0.1, including SE-0138, SE-0139 and SE-0140. Check the release notes for more information. Additionally, iOS 10.1 and macOS Sierra 10.12.1 had their final releases.

In other news, Apple is holding a “Mac-centric” event this morning where they are expected to announce new Macs. I know a lot of developers in the community have been waiting for this. I’m still crossing my fingers for a new Thunderbolt display. 🤓 Let’s hope the announcements are good!

News and Community

Chris Bailey from IBM wrote a blog post on Swift.org announcing the new Server APIs Work Group.

Since Swift became available on Linux there has been a huge amount of interest in using Swift on the server, resulting in the emergence of a number of Web Frameworks, including Kitura, Vapor, Perfect, and Zewo, along with many others. As an important part of the Swift ecosystem, and one that we are keen to foster, we are today announcing the formation of the Server APIs work group.

The Server APIs Project looks like an amazing step forward for advancing Swift on the server and it’s being driven by the community. The project’s goal is to provide core APIs (base networking, security and encryption, HTTP and WebSockets) for server development — think corelibs-foundation, but for the server. The Work Group is composed of a Steering Team and Stakeholders, including representatives for all of the popular Swift web frameworks — IBM Kitura, Vapor, Zewo, and Perfect. It’s really great to see the leaders from each of these projects come together to establish and collaborate on common, core functionality. Until now, server-side Swift has been very ad hoc and fragmented. I think formalizing this aspect of Swift with official support from Swift.org will only increase the momentum behind making Swift a first-class citizen (and first-choice for developers) on the server. If this doesn’t position server-side Swift for success, I don’t know what does. There’s more information on the new project page.

The Server APIs project will provide core capabilities in areas such as networking and security so Swift programs no longer need to frequently rely on platform-specific C libraries to provide this functionality. As a result, developers will be able to create frameworks and server applications using pure-Swift code, without the need to also have systems programming skills and knowledge of multiple platforms.

Erik Eckstein wrote a blog post on Swift.org titled Whole-Module Optimization in Swift 3. Not only does this article give an excellent overview of what whole-module optimization is and how it works, but it also provides a brief overview of how the Swift compiler works in this context.

There’s a (new?) UnsafeRawPointer Migration Guide on Swift.org that guides you through migrating code that uses the UnsafePointer APIs from Swift 2 to Swift 3.

Commits and pull requests

Doug Gregor committed a number of diffs to improve the constraint solver by lazily creating constraints. This work prevents preallocating constraints that will be immediately simplified anyway — which should bring some decent performance improvements to the compiler.

In light of the rejection of SE-0144, Robert Widmann submitted a pull request to disable the ability to use $ as an identifier. It looks like Swift 3.x releases will continue to silently accept $ as an identifier, but this will be an error in Swift 4.

Erik Eckstein fixed a bug where a constructor call of an open class is devirtualized although the call should be done dynamically.

@hyp patched swift-clang to display an objc_subclassing_restricted error for Objective-C implementation declarations when appropriate.

Erica Sadun diligently helped to update and maintain the Swift changelog.

@kstaring opened a pull request with a patch for FreeBSD compatibility.

Rejected proposals

Proposal SE-0144: Allow Single Dollar Sign as a Valid Identifier was rejected.

The majority of the feedback on this proposal was opposed to it, because it makes the Swift language complex for a single library. While it is unfortunate that this library is out in the wild and that there are some users, it was never intended for a single dollar sign to be allowed as an identifier, and it was also never documented as such. The core team believes that Swift 3 compatibility mode will be able to cleanly handle compatibility issues implied by not accepting this proposal.

Thank you to Ankur Patel for raising this proposal: it was important to get proper community discussion and feedback on this topic.

Mailing lists

There’s a new mailing list! The swift-server-dev list is a dedicated list for the new Server APIs Project. If you have any interest in server-side Swift or want to get involved, sign up! Chris Bailey from IBM sent the inaugural email.

[…] Whilst there is already strong participation from some of the more well know web frameworks, including Kitura, Vapor, Perfect, and Zewo, participation and contribution is open to everyone — whether that’s having a requirement or use case you’d like to share, bugs you want to report (once we have code!), code your willing to write, or just your thoughts on what’s needed.

Ted Kremenek also announced the Server APIs Project on swift-evolution-announce.

[…] The idea behind the work group is to have a way for the Swift.org community to prototype and design a core set of APIs for empowering Swift development for server development. This work group complements the evolution process on swift-evolution, whereby the work group will incubate new APIs and libraries that eventually will be brought back for formal review/proposal on swift-evolution. The work group, however, provides a focused forum to develop and discuss these new APIs. […]

Thanks so much to Chris Bailey for driving much of the effort to organize the work group.

Erica Sadun pitched an idea on reimagining guard case and if case. She proposed the following, simpler syntax using the pattern matching (~=) operator:

// Current (confusing)
if case range = myValue {
    // ...
}

// Proposed (simpler)
if range ~= myValue {
    // ...
}

Jacob Bandes-Storch shared a draft proposal on Refining Identifier and Operator Symbology in collaboration with Erica Sadun, Xiaodi Wu, and Jonathan Shapiro. The goal is to clarify which characters are valid operators versus valid identifiers and adopt Unicode recommendations.

This proposal seeks to refine and rationalize Swift’s identifier and operator symbology.

Finally

And finally — the Swift philosophy. 💩 (original email here.)