Issue #97 07 Dec 2017
Written by: Jesse Squires
Swift officially turned two years old this week, which means this newsletter is also two years old! It’s hard to believe. We’ve certainly come a long way, but there’s plenty of work to be done. Here’s to another great year of Swift!
Interested in sponsoring Swift Weekly Brief? Learn more here.
Swift Unwrapped
Episode 38: Off to the races. Think thread safety with Swift is the same as C languages, with slightly different syntax? Think again!
News and community
From Ted Kremenek:
Two years ago today Swift became open source. Thank you to everyone who has (and continues) to contribute to Swift to make it a vibrant project.
Xcode 9.2 was released, which ships with Swift 4.0.2. Slava Pestov noted:
Xcode 9.2 ships with Swift 4.0.2 which includes a large number of bug fixes, including several that y’all reported on Twitter
From Ankit Aggarwal:
If you write Swift scripts, add swiftpm as a dependency and try the new Utility product. It contains a nice collection of (cross platform) APIs, e.g. argument parser, in-memory filesystem, path, terminal controller, subprocess, sorted array etc
Greg Heo wrote an article on Swift Substrings and how they’re implemented. He also wrote about the implementation of @objc and dynamic. Both are great reads, with delightful diagrams that really help explain what’s happening under-the-hood. 🤓
Commits and pull requests
Doug Gregor made Codable conformances for Optional and collections conditional. “Array, Set, Dictionary, and Optional all provide unconditional conformances to Encodable & Decodable that dynamically check whether their type arguments are Encodable/Decodable. Now that we have conditional conformances, make these unconditional conformances properly conditional, removing all of the Swift 4-era type-erasure hacks.”
Max Moiseev improved the default implementation of Collection.distance(from:to:).
Previous versions of Swift accidentally treated lazy properties as computed properties because of how they were implemented. This has been fixed, but it’s a source-breaking change in Swift 5. Jordan Rose downgraded this error to a warning for Swift 4.1. It’s another interesting case in source compatibility and preserving “broken” behavior.
Philippe Hausler fixed a (rare) bug in Data in the Foundation SDK overlays that resulted in heap corruption.
Accepted proposals
SE-0189: Restrict Cross-module Struct Initializers was accepted.
During the review, most of the feedback voiced support that this was a necessary change for the library evolution (API resilience) story in Swift. There was some concern about the migration impact, as the change is source-breaking. Some options were discussed on the review thread to possibly mitigate the migration impact in some cases. Further, the thought process is that by having a warning in Swift 4.1 we can assess the impact of the change and soft message it, or if feedback is strong, re-evaluate the change.
SE-0191: Eliminate IndexDistance from Collection was accepted.
The proposal is accepted. Feedback for this simplification to the Collection protocols was positive.
Mailing lists
Doug Gregor wrote an RFC on associated type inference, aiming to remove parts of it and solicit feedback on a new approach. The topic was previously discussed last year.
Associated type inference, which is the process by which the Swift compiler attempts to infer typealiases to satisfy associated-type requirements based on other requirements, has caused both implementation problems and user confusion for a long time. Some of you might remember a previous (failed) attempt to remove this feature from the Swift language, in SE-0108 “Remove associated type inference”
I’m not sure we can remove this feature outright (i.e., the concerns that sank that proposal are still absolutely valid), because it is so very convenient and a lot of user code likely depends on it in some form or other. So, here I’d like to describe the uses of the feature, its current (very problematic) implementation approach, and a half-baked proposal to narrow the scope of associated type inference to something that I think is more tractable. I need help with the design of this feature, because I feel like it’s going to be a delicate balance between implementability and expressiveness.
[…]
What’s a Good Solution Look Like? Our current system for associated type inference and associated type defaults is buggy and complicated. The compiler gets it right often enough that people depend on it, but I don’t think anyone can reasonably be expected to puzzle out what’s going to happen, and this area is rife with bugs. If we were to design a new solution from scratch, what properties should it have?
Doug Gregor provided an update on conditional conformances. The main missing piece here is support for dynamic casting. Doug is looking for feedback on the team’s implementation approach, as this involves a metadata change that will affect the ABI. (And remember, ABI stability is a hard requirement for Swift 5.)
The main missing piece for conditional conformances (https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md) is support for dynamic casting. Right now, dynamic casting that queries a conditional conformance will always fail. […] We’d like to fix that :)
Joe Groff, Slava, and I discussed an approach to implement dynamic casting for conditional conformances, which I’d like to outline here.
Chris Lattner updated and shared his Python interop playground.
For anyone interested, here’s another update on this, including a bunch of operators, conformances to standard Swift protocols etc.
Chris Lattner also provided an update on the direction of the random number API being discussed.
The strong opinion of the core team is that such an API should not be designed with an attempt to service people writing crypto code. Such clients will have requirements that are difficult to predict or that are hard to provide in general (e.g. “must run in constant time”). These clients are also relatively few, compared the community of people who benefit from a good “general use” random number API.
As such, the core team strongly encourages the random number API design process to focus on building the best possible “general use” API, without worrying about the needs of crypto experts.
Beyond that, the core team did not discuss what the exact shape of the API should look like: it believes the community should continue hashing it out. We just wanted to remove one big constraint from that design process.
Finally
And finally — Xcode Spinner II.