So the lovely Greg took over last issue as I was at a conference, try! Swift NYC. I’ve had an amazing time at the conference (and New York) where I gave a talk about the history of Swift. A video of that talk will be posted in the future.

A big thank you goes out to the organizers, the volunteers and all of those who I got to meet at the conference!

We are also working on bringing back subscriptions via email. To cover the associated costs, we are looking for sponsors again.

We’re sharing more details soon. If you or your company are interested in sponsoring the newsletter, please send me a direct message on Twitter.

That being said, and without further ado, here is an update on everything Swift from the past two weeks.

Starter tasks

  • SR-8625 [Compiler] Swift should warn if a closures is passed to an argument that is an autoclosure
  • SR-8645 [Package Manager] BuildPlan error descriptions aren’t printed
  • SR-8646 [Package Manager] BuildPlan.Error.missingLinuxMain description rephrasing
  • SR-8671 [Package Manager] ARG_MAX limit exceeded when compiles huge project

News and community

Xcode 10 has been released, and alongside came Swift 4.2. Ted Kremenek wrote a blog post describing the changes in detail.

Ole Begemann did us all another huge favor by means of a What’s new in Swift 4.2 Playground. You should definitely give this a try if you want a quick and interactive overview of the new features in Swift 4.2.

On a related note, Paul Hudson wrote about what’s new in Swift 5. Besides ABI stability, there are some other interesting new improvements and features expected in that release. Swift 5 is expected to be released early 2019.

Commits and pull requests

Pavel Yaskevich merged a pull request making the constraint solver iterative rather than recursive, which should fix some stack overflow issues.

Joe Groff merged a pull request that finishes up the implementation of SE-0227 (see below). “Now we’re just waiting for tuple keypaths so we can have full parity between member access syntax and keypath syntax.” 🎉

Accepted proposals

SE-0227: Identity key path was accepted.

Feedback on the proposal was light but all positive, and the proposal was accepted without modifications.

Proposals in review

SE-0228: Fix ExpressibleByStringInterpolation is under review.

String interpolation is a simple and powerful feature for expressing complex, runtime-created strings, but the current version of the ExpressibleByStringInterpolation protocol has been deprecated since Swift 3. We propose a new design which improves its performance, clarity, and efficiency.

We see three general classes of types which might want to conform to ExpressibleByStringInterpolation:

  1. Simple textual data
  2. Structured textual data
  3. Machine-readable code fragments

The current design handles simple textual data, but struggles to support structured textual data and machine-readable code fragments.

Swift Forums

Ted Kremenek shared the next steps for the Swift Server work group.

As announced at try! Swift New York City, the Swift Server work group is now entering a new chapter in its evolution. With the release of SwiftNIO and it’s subsequent adoption by popular Swift web frameworks, Kitura and Vapor, the group is now ready to take on new tasks. It’s time to focus on defining and creating a set of libraries and tools that are focused on developing and deploying server applications written in Swift.

Read more about the new focus on the updated Swift Server work group page.

Tomer Doron shared new focus areas for the Swift Server work group.

[..] the work group came up with the following focus areas which we feel can make a real and immediate impact on the ecosystem. The list reflects what we previously heard from the community as well as our own personal experience writing server applications with Swift, and is designed to solve tangible needs that do not require new features from the language or core libraries.

  • Database Drivers and Storage Clients
  • Tooling and Production Readiness
  • Distributed Systems, Microservices and Event Driven Architecture

Xiaodi Wu shared news about a number of blog posts that go into detail of how numeric types work in Swift.

A great number of questions are raised in these forums as to the functioning and design of numeric types and protocols in Swift. Sometimes, the answer can be found only by digging through the source code, and even then it’s hard to place what you learn there within a larger context. Therefore, I’ve compiled a series of articles that delve into these topics in more detail.

You can find the blog posts here.

Joe Groff pitched a proposal to allow self = x in class convenience initializers.

In this pull request, I’m changing code generation for class convenience initializers so that they only have “allocating” entry points, which are responsible for allocating and initializing the entire object. (See Changing class convenience initializers to perform whole object allocation and @objc interop for more background.) With this change, convenience initializers are nearly identical to value or protocol extension initializers at the implementation level, since the self.init delegation within a convenience initializer is effectively initializing the self reference with a reference to the instance created by the self.init call rather than initializing the instance itself. At this point, it’s not that big of a leap to allow the self reference to also be initialized by assignment, as it can be in value and protocol extension initializers, like this:

class Y {
  required init() {}
  static func singletonInstance() -> Self { return self.init() }
  convenience init(pref: Y) {
    self = type(of: self).singletonInstance()
  }
}

This opens the door to convenience initializers being able to use static factory methods or other Self-returning operations to produce their returned result, not only the result of other initializers. Swift’s own standard library and Foundation overlay hack around this missing functionality by making classes conform to dummy protocols and using protocol extension initializers where necessary to implement this functionality:

protocol P {
  static func instance() -> Self
}

extension P {
  init() {
    self = Self.instance()
  }
}

class C: P {
  static func instance() -> Self { ... }

  convenience init(x: ()) {
    self.init()
  }
}

Finally

Swift can now even be found in Apple Watch bands. Who would’ve thought?!