This week on Swift Unwrapped we discuss SourceKit and the tumultuous tales of the community getting SourceKit compiling on Linux. Ted Kremenek announced that
swift-stdlib-tool will remain in Xcode, and Itai Ferber shared draft proposals for new Swift-focused archival and serialization APIs for Foundation.
Hello, it’s Paul Hudson again, still with Hacking with Swift, and still helping to support this awesome newsletter. Perhaps I should hire a marketing team. In the meantime, check out my Swift Power Pack – you get my first six books at the discounted bundle price of just $100.
In this week’s episode — SourceKit (Compiling by default) — we dive into the framework we love to hate to love: SourceKit. We wrap up with an overview of method dispatch in Swift. As always, let us know what you think. If you have a second, rate us on iTunes.
News and community
Ayaka Nonaka’s (@ayanonagon) talk from Swift Summit, Contributing to the Swift compiler, is now available. This talk is absolutely great. It was one of my favorites from Swift Summit. If you are interested in contributing, but not sure where to start, this is a must-watch video! You can find the slides here.
Last week the community was concerned about the removal of
swift-stdlib-tool. Brian Gesiak (@modocache) wrote a post, Why do I care about swift-stdlib-tool?, to explain why this is command line tool is so important for the community. After what I can only imagine were a lot of radars, Ted Kremenek confirmed that Xcode 8.3 will ship with
John Regehr wrote an awesome article, A Tourist’s Guide to the LLVM Source Code. This isn’t new (written in January 2017) but I’m sure it’s recent enough to still be relevant. Thanks to Brian Gesiak for sharing this week. If your interest in Swift runs deeper than Swift itself and you want to get involved in LLVM, this looks like a fantastic resource.
Commits and pull requests
This gives big code size wins for unused types and also for types, which are never used in a generic context. Also it reduces the amount of symbols in the symbol table. The size wins heavily depend on the project. I have seen binary size reductions from 0 to 20% on real world projects.
No updates on proposals this week! Check the status page for details.
Currently under active review:
- SE-0158: Package Manager Manifest API Redesign
- SE-0157: Support recursive constraints on associated types
- SE-0156: Class and Subtype existentials
The following introduces a new Swift-focused archival and serialization API as part of the Foundation framework. We’re interested in improving the experience and safety of performing archival and serialization, and are happy to receive community feedback on this work. Because of the length of this proposal, the Appendix and Alternatives Considered sections have been omitted here, but are available in the full proposal on the swift-evolution repo. The full proposal also includes an Unabridged API for further consideration.
From the proposal introduction:
Foundation’s current archival and serialization APIs (
NSPropertyListSerialization, etc.), while fitting for the dynamism of Objective-C, do not always map optimally into Swift. This document lays out the design of an updated API that improves the developer experience of performing archival and serialization in Swift.
- It aims to provide a solution for the archival of Swift
- It aims to provide a more type-safe solution for serializing to external formats, such as JSON and plist
This is great news! This is certainly something that the community has wanted for awhile. I’m sure Nick O’Neill would be happy to stop maintaining Pantry, a library built to solve this problem.
Further, Itai followed up with a companion proposal for Swift encoders:
From the proposal introduction:
As part of the proposal for a Swift archival and serialization API (SE-NNNN), we are also proposing new API for specific new encoders and decoders, as well as introducing support for new
This proposal composes the latter two stages laid out in SE-NNNN.
And finally — Does this mean Swift and ObjC are webscale now?