I’ve returned! 😊 Welcome back to the weekly. We skipped last week and I haven’t written the last few issues, but luckily we have some amazing contributors to help bring this to your inbox each week. Big thanks to Bas, Brian, and Roman. I was traveling and speaking at iOS Conf Singapore and then the very first try! Swift India — both of which were great!
This week, we saw a progress on conditional conformances, a few new proposals, and discussions on Swift interop with Python.
Interested in sponsoring Swift Weekly Brief? Learn more here.
Episode 37: Enum case enumerable proposal: JP and Jesse discuss the popular, long ago deferred proposal for enumerating all cases of an enum.
News and community
All of the videos from iOS Conf Singapore last month have been posted. There’s a playlist on YouTube. While this is an iOS conference, there was no shortage of talks specifically about Swift:
- Slow Swift, Marcin Krzyzanowski
- Exploring Swift’s numeric types and protocols, Jesse Squires
- To be! Or not? Optionals in practice, Rob Napier
- Strings in Swift, Omer Iqbal
- Codeable in Swift 4, Sam Davies
Brian Gesiak continued his Swift compiler series this week with a new post, Reading and Understanding the Swift Driver Source Code.
Greg Heo crafted an excellent diagram of the Swift compilation flow. 😆
Commits and pull requests
Daniel Dunbar opened a work-in-progress pull request to allow swift-llbuild to be used via the Swift Package Manager.
Simon Evans merged a pull request that adds Darwin compatibility tests to corelibs-foundation. “This allows tests to be validated against the native Foundation and is useful for checking edge cases…”
Chris Lattner drafted his proposal, Introduce User-defined “Dynamic Member Lookup” Types and implemented the proposed
DynamicLookupProtocol in the std lib. This lays the necessary groundwork for interoperating with scripting languages like Python (discussed below).
Nate Cook improved support for large (
DoubleWidth) integers in the std lib.
Xiaodi Wu merged changes that eliminate intermediate rounding error in floating-point strides.
Ben Cohen made progress on Swift’s conditional conformances, adopting them for
During the review, support for the enhancement was unanimous. There were some questions during the review about the capabilities of this feature. Graydon explained that his is largely surfacing target environment information from the target triple, which can be flexibly used in many circumstances.
Thanks to everyone who participated in the review.
During the review, the only point of discussion was whether to go one step further and make conformance to Hashable a requirement for all Collection indices. While this would be a source-breaking change, the core team are receptive to this proposal being pitched and discussed as a separate evolution proposal if it covered the handling of the source compatibility issues.
Thanks to everyone who participated in the review.
Proposals in review
Eliminate the associated type
Collection, and modify all uses to the concrete type
Collectionallows for the distance between two indices to be any
SignedIntegertype via the
IndexDistanceassociated type. While in practice the distance between indices is almost always an
Int, generic algorithms on
Collectionneed to either constrain
IndexDistance == Intor write their algorithm to be generic over any
Swift 4.0 introduced the ability to constrain associated types with
whereclauses (SE-142) and will soon allow protocol constraints to be recursive (SE-157). With these features, writing generic algorithms against
Collectionis finally a realistic tool for intermediate Swift programmers. You no longer need to know to constrain
SubSequence.Element == Elementor
SubSequence: Collection, missing constraints that previously led to inexplicable error messages.
At this point, the presence of
IndexDistanceis of of the biggest hurdles that new users trying to write generic algorithms face. If you want to write code that will compile against any distance type, you need to constantly juggle with explicit type annotations (i.e. you need to write
let i: IndexDistance = 0instead of just
let i = 0), and perform
numericCastto convert from one distance type to another.
Graydon Hoare shared updates about ongoing work related to compilation performance.
This is just an update on some work that’s been ongoing in the past several months related to tracking and improving Swift compilation performance. I’ve been helping coordinate some of that work: documenting what’s known about compilation performance patterns and diagnostic machinery, increasing visibility and process controls around compilation performance, and also helping making some changes directly to the compiler.
I wanted to post here to make sure everyone’s aware of what’s currently going on, as well as solicit feedback on priorities and ways to help others interested in the topic.
Here’s a bit of an overview of recent activities:
Graydon covers compilation-performance testing, measurements, scale testing, reducing quadratic costs, and improving incremental mode. I highly suggest reading the full email and following the links, especially the Swift Compiler Performance doc.
Nicole Jacque started the discussion on moving swift-evolution from their current form to Discourse.
As Ted Kremenek has previously announced, we are in the process of moving the Swift mailing lists to Discourse. Previously the discussion was mostly about moving swift-evolution over to a forum, but the consensus from Ted and the Core Team was that should look to move all the lists to Discourse for consistency.
I will be shepherding the transition from the mailing lists to the forum. Rather than simply move the existing lists and structure as-is, we’d like to take this opportunity to explore new ways of organizing the forums to help foster communication and collaboration. We also have a number of new options that will be available with Discourse, that we’d like some input from the community on.
To help with this, I am looking for 3-4 volunteers from the Swift community to create a workgroup to discuss and create a plan for the structure for the Discourse-based forums. We will then present this plan back to the community. We are also investigating the possibility of having a preview version of the forums available for comment from the community.
If you would like to be part of this workgroup, please reply back to me and let me know!
Chris Lattner discussed Python interoperability with Swift:
As I mentioned on a couple other threads, I’ve been working on improving Swift interoperability with Python. I have two pitches out: one to improve Python member lookup and one to improve calls to Python values. While those proposals are important, I think it is also useful to see what can be accomplished with Swift today.
To show you how far we can get, here is a Swift playground (tested with Xcode 9) that has an example interoperability layer, and a tutorial for using it. If you’re interested in the pitches, or in Python, please check it out.
In addition to showing how far the interop can go today (which is really quite far) it shows what the future will look like assuming the member lookup and call issues are resolved. To reiterate what I said on the pitch threads, I am not attached at all to the details of the two pitches themselves, I simply want the problems they address to be solved.
Finally, of course I also welcome questions and feedback on the actual approach, naming, and other suggestions to improve the model!