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.
Sponsored Link
Swift Power Pack
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.
Swift Unwrapped
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 swift-stdlib-tool. 🎉
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
Robert Widmann (@CodaFi) resolved 22 compiler crashers and then followed that up by fixing 24 more! 😱 Slava (known for smashing tons of bugs) better watch out! 😆
Slava Pestov (@slavapestov) fixed a crash when calling a method on a generic base class with a concrete subclass, which has been broken since at least Swift 2.
Erik Eckstein (@eeckstein) merged changes to IRGen to emit type metadata and (value) witness tables lazily, which could result in binary size reductions up to 20 percent! 🙌
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.
Andrew Bennett (@therealbnut) added benchmarks for dropLast and suffix in the stdlib.
The Swift server work group held their second HTTP stream meeting. Chris Bailey (@seabaylea) has posted the initial meeting notes, though they are currently empty.
Proposals
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
Mailing lists
Itai Ferber (@itaiferber) started a thread with a proposal draft for a new Swift-focused archival and serialization API for Foundation.
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 (
NSCoding,NSJSONSerialization,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.Specifically:
- It aims to provide a solution for the archival of Swift
structandenumtypes- 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:
This is a companion proposal to the Foundation Swift Archival & Serialization API. This introduces new encoders and decoders to be used as part of this system. The proposal is available online…
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
Codabletypes inNSKeyedArchiverandNSKeyedUnarchiver.This proposal composes the latter two stages laid out in SE-NNNN.
Finally
And finally — Does this mean Swift and ObjC are webscale now?