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.

有兴趣赞助 Swift Weekly Brief？点击这里

Swift Unwrapped

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:

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.

Keith Smiley fixed a bug in lldb for using enums as Swift dictionary keys, SR-6290. Definitely a strange edge case! (pun intended 😉)

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…”

Doug Gregor merged changes to use conditional conformances to implement Equatable for Optional, Array, and Dictionary. He also merged minor optimizations for protocol conformances.

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 Indices, Slice, and ReversedCollection.

Accepted proposals

SE-0190: Target environment platform condition was reviewed and accepted. You can find the implementation here.

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.

SE-0188: Make Standard Library Index Types Hashable was accepted.

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

SE-0191: Eliminate IndexDistance from Collection is under review. You can find the implementation here.

Eliminate the associated type IndexDistance from Collection, and modify all uses to the concrete type Int instead.

Collection allows for the distance between two indices to be any SignedInteger type via the IndexDistance associated type. While in practice the distance between indices is almost always an Int, generic algorithms on Collection need to either constrain IndexDistance == Int or write their algorithm to be generic over any SignedInteger.

Swift 4.0 introduced the ability to constrain associated types with where clauses (SE-142) and will soon allow protocol constraints to be recursive (SE-157). With these features, writing generic algorithms against Collection is finally a realistic tool for intermediate Swift programmers. You no longer need to know to constrain SubSequence.Element == Element or SubSequence: Collection, missing constraints that previously led to inexplicable error messages.

At this point, the presence of IndexDistance is 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 = 0 instead of just let i = 0), and perform numericCast to convert from one distance type to another.

Mailing lists

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:

Continue reading…

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!

Finally

And finally — A team of iOS developers prepare to type-erase a protocol with associated types.