With 1,653 votes, this Twitter poll shows a majority of people building their current and future macOS/iOS apps in Swift. The poll is a good reminder that many professional app developers now rely on the Swift compiler, even as it continues to rapidly grow and change. On the one hand, that means contributors like you and I can have a positive, immediate impact on many developers. On the other hand, there’s a great deal of people who may be inconvenienced by a bug, so maintainers will need to be careful about how to vet contributions.

How has Swift grown this week? In this brief, we discuss conditional protocol conformances, building the Swift runtime for Android from a macOS host machine, improved diagnostics, and proposals to add compile time debugging options.

Starter tasks

Do you have experience writing Python, and want to learn more about the tools used to test Swift, Clang, and LLVM? Daniel Dunbar has asked for help maintaining lit, the LLVM Integrated Tester. You can follow the LLVM Getting Started Guide to download the LLVM source code. LLVM uses Phabricator for code reviews, and you can learn how to use it here. Brian Gesiak added instructions on how to run lit’s test suite, and where to look for work to be done.

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

Commits and pull requests

Swift 3.0.1 Preview 1 has been released.

Shortly after it was featured in last week’s brief, Erik Eckstein fixed a bug that forced internal Foundation and XCTest symbols to be marked as public. Thanks to this, Brian Gesiak was able to correct access controls for API in XCTest.

Joe Groff implemented the second half of SE-0139 by bridging Swift numeric types to Objective-C NSNumber.

Andrew Trick implemented evolution proposal SE-0138, adding UnsafeRawBufferPointer and UnsafeRawMutableBufferPointer to the standard library.

Brian Gesiak sent a pull request that allows macOS host machines to compile the Swift runtime for Android. Previously only Linux machines could compile for Android.

Work continues to improve compiler diagnostics. Harlan Haskins fixed a compiler assertion that occurred when incorrectly using var for type-inferred parameters in closures, such as takesClosure { (var d) in d }. With Harlan’s change, this now produces the error “parameters may not have the ‘var’ specifier”. Mark Lacey fixed this confusing error message:

func foo(x: Int, _ y: Int) -> Int {
  return x + y
}

func bar() -> Int {
  return foo(3, 5) // error: unnamed argument #2 must precede unnamed argument #1
}

Mark’s work corrects the error message:

func bar() -> Int {
  return foo(3, 5) // error: missing argument label 'x' in call
}

Dave Abrahams uploaded a work-in-progress pull request from Maxim Moiseev that implements SE-0104, protocol-oriented integers. If you’re curious what pull requests look like before they’re ready to merge, take a look!

@lplarson added an option to the script used to build the Swift compiler that allows it to be built with profile guided optimization. It’ll be interesting to see whether this results in improved Swift compiler performance! To learn how you can use this advanced Clang feature in your own applications, read Apple’s documentation.

Eli Perkins marked UnicodeScalar.utf16 and UnicodeScalar.UTF16View as public, completing one of the starter tasks introduced in last week’s brief. Despite being a “starter” task, it almost turned into a Swift evolution proposal – phew!

Daniel Müllenborn added a badge to the Swift README that displays the build status of Swift on Ubuntu 16.04. Swift now runs on Ubuntu 14, 15, and 16.

Ben Rimmington added support for proposals implemented in Swift 3.0.1 and 4.0. SE-0140 is now missing from the site, although it has already been implemented.

Proposals in review

Proposal SE-0141: Availability by Swift version from Graydon Hoare is under review.

Swift’s existing @available(...) attribute indicates the lifecycle of a given declaration, either unconditionally or relative to a particular platform or OS version range.

It does not currently support indicating declaration lifecycle relative to Swift language versions. This proposal seeks to extend it to do so.

Proposal SE-0142: Permit where clauses to constrain associated types from David Hart, Jacob Bandes-Storch and Doug Gregor is under review.

This proposal seeks to introduce a where clause to associated type declarations and improvements to protocol constraints to bring associated types the same expressive power as generic type parameters.

Proposal SE-0143: Conditional Conformances from Doug Gregor, is under review. The proposal is a big part of the generics manifesto, and will likely have a large impact upon Swift code in the standard library and beyond.

Conditional conformances express the notion that a generic type will conform to a particular protocol only when its type arguments meet certain requirements. For example, the Array collection can implement the Equatable protocol only when its elements are themselves Equatable, which can be expressed via the following conditional conformance on Equatable:

extension Array: Equatable where Element: Equatable {
  static func ==(lhs: Array<T>, rhs: Array<T>) -> Bool { ... }
}

Mailing lists

Brian Michel proposed adding options for the compiler to output structured information about compilation times.

Daniel Dunbar noticed a large regression in how long it took to compile the Swift package manager source code. It appears a change in LLVM has caused the issue, but what exactly caused it has yet to be pinpointed.

Finally

What’s the most Swift emoji you can think of? 🤔