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.
- 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
Jesse and JP discussed SourceKit-LSP (Language Server Protocol), an implementation of the LSP for Swift and C-based languages.
News and community
Commits and pull requests
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. 🏎
Proposals in review
Codableconformance for some types in the standard library, but not the
Rangefamily of types. This proposal adds that conformance.
Rangeis 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
We propose to change the Swift APIs for the Apple’s unified logging system (namely,
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)").
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.
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.
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?