Hello all, and a belated happy New Year! May 2019 be a wonderful year to all of you… and Swift!

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-9466 [Compiler] Redo AssignInst lowering in DI
  • SR-9482 [ClangImporter] Swift’s filtering of “header guard” macros is too strict
  • SR-9557 [IRGen] Objective-C property description includes ivar name even when getters and setters are non-trivial
  • SR-9558 [SwiftPM] Improve error message when test directory is missing

Swift Unwrapped

Jesse and JP discussed SourceKit-LSP (Language Server Protocol), an implementation of the LSP for Swift and C-based languages.

News and community

Saleem Abdulrasool shared nightly builds for Swift on Windows! “This has sufficient bits built and packaged to be semi-usable”; a job well done!

John McCall shared some interesting thoughts on open source language project management that is valid for Swift.

Commits and pull requests

David Smith merged a pull request improving NSDictionary to Swift.Dictionary bridging! 🎉

Doug Gregor merged a pull request that enables shadowing for type lookups, which allows for Swift’s Result not to cause any source-breaking changes as a result (no pun intended)!

Bruno Rocha merged a pull request that allows folding code structures for the Swift Language Server Protocol.

Argyrios Kyrtzidis merged a pull request exposing parser details as a C API, allowing Swift clients, such as SwiftSyntax, to reuse compiler logics in-process. That then gives a significant performance gain for syntax tree generation by avoiding any forms of cross-process serialization. 🏎

Pavel Yaskevich merged a pull request diagnosing missing members via the new diagnostics framework.

Suyash Srijan merged a pull request that adds a warning if usage of a .none enum case is ambiguous.

Proposals in review

SE-0239: Add Codable conformance to Range types is under review.

SE-0167 introduced Codable conformance for some types in the standard library, but not the Range family of types. This proposal adds that conformance.

Range is a very useful type to have conform to Codable. A good usage example is a range being sent to/from a client/server to convey a range of time using Date, or a safe operating temperature range using Measurement<UnitTemperature>.

Swift Forums

Ravi Kandhadai Madhavan wrote about improving Swift APIs for Apple’s unified logging systems.

We propose to change the Swift APIs for the Apple’s unified logging system (namely, os_log and os_signpost) to accept string interpolations instead of the printf-style format string and varargs combination that they currently accept. This means Swift users can pass in string interpolations to the logging functions e.g. like osLog("Fatal Error \(errno)").

Johannes Weiss shared a revised proposal pitch for the Swift Server logging API.

We have integrated most of the feedback from the discussion thread so even if you have read the previous version, you will find some changes that you hopefully agree with. To highlight a few of the major changes:

  • Logging metadata is now structures and now supports nested dictionaries and list values, in addition to strings of course.
  • only locally relevant metadata can now be passed to the individual log methods.
  • ship a multiplex logging solution with the API package

The feedback model will be very similar to the one known from Swift Evolution. The community is asked to provide feedback in the way outlined below and after the review period finishes, the SSWG will – based on the community feedback – decide whether to promote the proposal to the Sandbox maturity level or not.

Ben Langmuir shared some thoughts on building, testing and installing Swift packages.

We have a number of SwiftPM packages (swift-syntax, sourcekitd stress tester, and now SourceKit-LSP) that we want to be able to build, test and install along with the rest of the Swift toolchain in continuous integration and packaging infrastructure. I started looking into this to add sourcekit-lsp to Swift CI, and I ran into a number of difficulties. The key challenge is that we want to build and run these packages using the just-built toolchain, including the compiler, package manager, and corelibs, but our tooling is not setup well for that. The rest of this post dives into what the problems are and how I propose we tackle them.

Scott Perry pitched a proposal for “diffing” of ordered collections.

I’d like to pitch the formalization of ordered collections as well as the addition of diffing functionality and related types necessary to provide easy creation, representation, and application of ordered collection state transitions.


It’s not only programming languages that are hard… or is it?