Swift 4.1 is
official, and lays a lot of groundwork ahead of the language’s most important update,
which is coming later this year. While any dot-x release is considered minor, Swift 4.1 adds key features to support the upcoming Swift 5, which is
due to go live this Fall. With Swift 5 comes ABI stability, and a true turning point for the language. Version 4.1 has some interesting tweaks of its own, all introduced at the behest of the Swift community at-large. It also adheres to the Generics Manifesto, an outline for where the language is headed long-term. With this update, Apple upgraded conditional conformance, synthesized equatable and hash conformance, made standard library index types hashable, made sure Swift supports recursive constraints and associated types, and introduced Sequence.compactMap() to replace the flatMap feature. Apart from high-level language changes, Swift 4.1 also introduces a handy ‘code size optimization’ feature. As you may have deduced from its naming scheme, it’s a compiler upgrade that hopes to maintain runtime performance while reducing the number of lines of code your apps need. A new ‘-0size’ option in the optimization settings within Xcode can lead to a huge reduction in file size. As Apple writes: “We have seen that using -0size reduces code size from five percent to 30 percent for some projects." It also cautions that -0size is best for apps that are “not super performance sensitive.” [caption id="attachment_140186" align="aligncenter" width="2048"]
Swift Source Stability is also critical for versions 4.1 and 5.[/caption]
Swift, ABI Stability, and Beyond
Swift 4.1 also makes seven changes to help the language achieve ABI stability for version 5. Here’s the full list:
- Use word-size field in native object header for reference counting (SR-4353)
- Review the efficiency of interacting with the enum discriminator through the witness table (SR-4332)
- Decide the layout of existential type metadata, including protocol descriptors (SR-4341)
- Define canonicalization of generic and protocol requirements for order-agnostic mangling (SR-3733)
- Audit of every runtime function for desirability and behavior (SR-3735)
- Enforce appropriate constraints on Sequences and Collections (SR-3453)
- Collapse various collection wrappers using conditional conformance (SR-3458)
Swift 4 was released alongside iOS 11 in September, which was around the time we first learned of ABI stability coming in version 5, and the team published its manifesto. At the time, Swift leader Ted Kremenek said ABI stability “focuses mostly on getting a bunch of low-level implementation details of the language finalized.”
When examining the ‘
ABI Stability’ section on swift.org, we see that ‘data layout’ is where most of the work to gain ABI stability needs to occur. There are also lingering issues to be resolved in calling, type metadata, runtime, standard library, and mangling. We should also note that many tasks have yet to be addressed, and have no status or noted availability timelines. The second focus area for Swift is the server, where the team feels the language has “amazing potential.” Luckily, that work is already proving its worth. SwiftNIO,
a non-blocking I/O tool for server-side Swift functionality, was recently released; although largely unheralded, it nonetheless has seen its share of acclaim from those in the know. Vapor, a server-side Swift service in its own right, was already one of the better solutions for such use-cases. It began work on SwiftNIO straight away and trimmed a ton of code from its base; future releases will be built atop SwiftNIO:
If the end-game is ABI stability with a healthy dose of server-side functionality – and it sure seems to be – then we’re over halfway there. SwiftNIO has a huge partner already, and likely more who will jump onboard. ABI stability seems on-track for a September(ish) release with version 5.
