And so, another two weeks have passed. For me, time seems to pass so quickly and yet at the same time, slowly.

We’re now about a month away from WWDC20 “taking off” — what that means exactly is still a surprise, but I’m very much looking forward to it.

Also, today’s issue coincides with Global Accessibility Awareness Day (GAAD). It’s a topic very dear to me. There are some tasks on this website’s repository that aim to make the site more accessible. Any help on those would mean the world to me.

After all, I took over the curation of this newsletter from Jesse because I wanted to keep sharing what’s happening in Swift open source with all those others benefiting from it.

There are also still sponsorship opportunities for the newsletter, and I would greatly appreciate it if you could share that with those who might be interested in helping with the newsletter in that way. It allows us to keep delivering it to your inbox every other Thursday!

Anyway… there’s also news!

Interested in sponsoring Swift Weekly Brief? Learn more here.

News and community

Swift 5.3 is going to be released soon, and Larry provided a great overview of what’s included.

Tim Condon wrote an article discussing the future of server-side Swift.

Vinicius Vendramini announced Gryphon, a Swift to Kotlin translator — a project he’s been working on for the past three (!) years.

Commits and pull requests

Mike Ash opened a pull request that adds a utility that can attach to a running Swift process and inspect/debug the runtime’s behavior.

Doug Gregor merged a pull request allowing the Swift Package Manager to optionally use the new swift-driver, making it much easier to try it out for your own projects.

Accepted proposals

SE-0283: Tuples Conform to Equatable, Comparable, and Hashable was accepted.

Almost all the feedback we received was positive, and the Core Team is convinced that this is a great incremental step forward. Some excellent points on possible concern over future tech debt in the compiler and runtime were brought up, but the Core Team believes that it is manageable and that this proposal helps push Swift forward in a positive direction.

Swift Forums

Dan Loman pitched a proposal to add firstAs() to Sequence.

I often find it necessary (and I imagine this is somewhat common) to find and cast the first matching element of a sequence. There are of course a few techniques that could be used to do this. For example:

sequence.filter { $0 is MyType }.first as? MyType
sequence.compactMap { $0 as? MyType }.first
sequence.first { $0 is MyLongTypeName } as? MyLongTypeName
if let element = sequence.first(where: { $0 is MyLongTypeName }) as? MyLongTypeName {
    // do something
}

The last option should leave us with the fewest iterations and is the option I’ve chosen to implement as a simple helper in a number of my projects.

This can allow for very compact, straightforward, and efficient calls to find the first element you’re looking for:

// explicit type
if let element = sequence.firstAs(MyType.self) {
    // do something
}
// inferred type
if let element: MyLongTypeName = sequence.firstAs() {
    // do something
}
// inferred type
let label: UILabel?

switch searchArea {
case .subviews:
    label = subviews.firstAs()
case .arrangedSubviews:
    label = stackView.arrangedSubviews.firstAs()
}

Kumar C pitched a proposal to use -> instead of curly braces for single expression bodied property getters, subscripted getters and functions.

As of SE-0255 developers can omit the return keyword for single-expression bodied getters for properties, subscripts and single expression bodies functions. This is a nice improvement to the language. Here’s an even more improved version of the same proposal.

Existing Syntax for Properties

var location: Location { .init(latitude: lat, longitude: long) }

Proposed Change

var location: Location -> .init(latitude: lat, longitude: long)

Becca Royal-Gordon pitched a follow-up proposal to cross-importing overlays.

Cross-import overlays allow Swift to automatically import additional “overlay” modules based on the combination of imports in a particular source file. They allow one library or framework to seamlessly offer tailored APIs for interoperating with another, without imposing additional dependencies or code on clients who don’t need it.

This feature has now been implemented and is in master and 5.3 nightly compilers, hidden behind the -Xfrontend -enable-cross-import-overlays flag. The proposal has been rewritten and reflects the implementation in the nightlies.

Tim Condon pitched a proposal to enable test discovery on Linux by default.

Swift 5.1 introduced Test Discovery on Linux adding an --enable-test-discovery flag you could pass to swift test so it would automatically pick up tests on Linux to run, without having to manually specifying them, which is prone to problems.

Since this has been in use for several months now without major issues, I propose we enable the flag by default. This simplifies testing on Linux, stops build errors when building on Linux without a LinuxMain.swift present and no flag, and generally makes life a bit easier, especially for newcomers.

Saleem Abdulrasool pitched a proposal to add policies for Swift platform development.

In order to create a stable ecosystem for Swift, it is important that we maintain a single coherent ecosystem across platforms. Whenever technical feasible, the project should aim to provide the same interfaces, behaviours, and capabilities on every platform. For example, the compiler and build system should support both static and dynamic linking of libraries on all platforms.

Owen Voorhees brought up required changes to his proposal on multiple variadic parameters in functions.

I’m currently looking into whether my proposal for multiple variadic parameters in functions will need any updates now that SE-0279 is accepted. While experimenting with the implementation on master, I noticed the following is not allowed:

func foo(bar: () -> (), baz: () -> ()..., qux: () -> ()) {}
foo {} baz: {} _: {} _: {} qux: {} // error: extra arguments at positions #4, #3, #3, #4 in call

I assume this is mostly a consequence of the backwards scan argument matching rule, but is it the intended behavior (the error message indicates it may just be a bug)? The proposal text doesn’t mention varargs. I think choosing to allow it or disallow it would both be reasonable, but it would be nice to specify the intended behavior a little more clearly.

Finally

Finding closure. { _ in }