Last week we saw the introduction of a new Swift Community Podcast. The podcast is set up in a similar way (and inspired by) this very Newsletter, fostering the Swift Community, encouraging anyone to help out.

I think this is a really exciting project and am looking forward to seeing the Swift community bring it to life!

And without further ado, here is an update on the last two weeks in Swift open source.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-9670 [Compiler] Driver should accept -serialize-diagnostics-path for the interpret mode
  • SR-9677 [Compiler] Using break with unresolved label inside loops produces misleading diagnostic

Podcasts

John, Garric and Chris introduce the Swift Community podcast, talking about its concept and their first impressions of Swift.

News and community

Jeremy Howard finished a research project trying to answer the question: is Swift a good language for high performance numeric programming in Mac and Linux?

I think this has the potential to be great for data science.

Joe Groff shared a prototype implementation of opaque result types.

Commits and pull requests

Arnold Schwaighofer merged a pull request that has non-escaping context allocated on the stack.

John McCall merged a pull request that combines two code paths, fixing an edge case neither one could handle. 🎉

Accepted proposals

SE-0239: Add Codable conformance to Range types was accepted.

Thank you everyone for the very insightful feedback provided during this review. It provided some great insights into the Swift’s community uses and desires on Codable.

Regarding the proposal itself, the Core Team has decided to accept it, with the proposal amended to include the details of the encoding format chosen. The data encoding chosen is an important semantic invariant of the API that is potentially observable by users and important for binary compatibility. Future proposals like this one that discuss adopting Codable should include details — and when necessary — rationale on the encoding chosen. Further, it would be valuable if the current chosen encodings for Standard Library types were also documented so that users using the default encodings for those types can either rely upon those encodings or know when they need to customize their encoding logic for a specific task.

In addition, the Core Team decided to extend the proposal to include Codable conformance for ContiguousArray, which was similarly missing from the Standard Library. This felt like a case that required no additional review discussion.

Proposals in review

SE-0240: Ordered Collection Diffing is under review.

This proposal describes additions to the standard library that provide an interchange format for diffs as well as diffing/patching functionality for ordered collection types.

Representing, manufacturing, and applying transactions between states today requires writing a lot of error-prone code. This proposal is inspired by the convenience of the diffutils suite when interacting with text files, and the reluctance to solve similar problems in code with libgit2.

Many state management patterns would benefit from improvements in this area, including undo/redo stacks, generational stores, and syncing differential content to/from a service.

Swift Forums

Stephen Celis and Greg Titus shared a proposal pitch to allow key path expressions as functions.

One-off closures that traverse from a root type to a value are common in Swift. Consider the following User struct:

struct User {
    let email: String
    let isAdmin: Bool
}

Applying map allows the following code to gather an array of emails from a source user array:

users.map { $0.email }

Similarly, filter can collect an array of admins:

users.filter { $0.isAdmin }

These ad hoc closures are short and sweet but Swift already has a shorter and sweeter syntax that can describe this: key paths.

LoĂŻc Lecrenier shared a pitch to support fuzz testers for Swift packages.

Recently, I wrote a coverage-guided Swift fuzzer similar to libFuzzer, but I found that SwiftPM did not allow me to specify the build settings I needed, and I had to fork SwiftPM to make my project work.

Using a coverage-guided fuzzer requires the tested targets to be instrumented with LLVM’s SanitizerCoverage, which is kind of possible to do now with the option -sanitize=fuzzer when using a development version of swiftc. And it is possible to add that option to a package because SwiftPM supports custom build settings thanks to SE-0238, but only for targets that are declared in the root package, not for targets declared in a dependency.

Moreover, instrumenting a target makes its resulting binary unfit to be used for any other purpose than fuzzing, so I believe it would be best to isolate the products of a “fuzzing” build by using a separate build configuration than debug or release.

Saleem Abdulrasool shared a progress update on Swift for Windows.

Working my way through the swift-corelibs-foundation for Windows, I think I have gotten to the point where I believe that the last items preventing Windows support for Foundation can now be enumerated:

  • Porting the remaining interfaces in Process, Thread, FileManager, and Host
  • Fixing the VWT handling for ForeignClassMetadata strategy
  • Fixing protocol witness table emission to be exported from the standard library
  • Identifying the desired behaviours for curl/libxml2 linkage

The first three are more technical, the implementation for the interfaces just need someone dedicated enough to work through the surface and with some time. The second would be something that is more involved, the third is just a bug.

[..] For those interested in the rest of the Windows port, especially those interested in helping getting Foundation running on Windows, do checkout the work in progress pull request. I would certainly love some help!

Finally

// Welcome to the world of software development.