This week we launched the Swift Unwrapped podcast! While Swift 3.1 development is chugging along with fixes and refinements, there’s worry in the community about the removal of swift-stdlib-tool from Xcode 8.3 beta. Also, this week will be known as “bring your own submodule proposal” week — there have been a number of different proposals on the topic.

Swift Unwrapped

This week JP Simard and I launched our new podcast, Swift Unwrapped! We plan to discuss the Swift language, its evolution and development, the Swift.org open source projects, and general Swifty news. Think of it as an extension of and commentary on this newsletter where we’ll be doing deep dives on various topics and elaborating on concepts in greater detail. Our first episode is a retrospective on the first full year of open source Swift development, reflecting on where we’ve been and how we got here. You can subscribe on iTunes. If you enjoy it, please consider leaving us a rating or review on iTunes!

News and community

When it comes to supporting Swift, Google and Facebook appear to have something in common: their build tools rely on the existence of swift-stdlib-tool, an Apple utility built into Xcode, which copies the Swift runtime into an application bundle. For an in-depth look at swift-stdlib-tool, consider reading this Technical Q&A by Samantha Marshall (@queersorceress). (And don’t forget to click on the “Donate” button at the bottom of that page.) Dmitry Shevchenko (@dmishe89) reported that swift-stdlib-tool has been removed in Xcode 8.3b2, and filed an Apple Radar. If you use Bazel or Buck to compile iOS apps, and you’d like those tools to support Swift, you could help by duplicating the Radar.

Nick Lockwood released v0.25.0 of his SwiftFormat tool, which now supports custom header comment templates, hoists var/let out of patterns, and more.

Ole Begemann shared a tip for checking if a specific commit will be included in Swift 3.1:

To check if a specific commit will make it into Swift 3.1:

git branch -r --contains <commit>

and look for origin/swift-3.1-branch.

Commits and pull requests

Slava Pestov (@slava_pestov) fixed a conformance lookup issue. When substituting a type like T.A.B where A and B are associated types and the conformance requirement on T.A is implied by conformance requirements on T, the compiler would crash. This is a regression that I ran into recently in the latest Xcode beta. This was one of those times where having access to the Core Team via Twitter, and having Swift open source on GitHub really made a difference for me!

Jordan Rose (@UINT_MIN) landed an epic bug fix. (master PR, 3.1-branch PR) It’s super interesting. I’d recommend reading the pull request descriptions and commit messages if you’re curious about the details. In short, this bug led to nonsensical errors like 'C.Iterator' is not the same type as 'C.Iterator', which I’ve seen before. And verifying the fix only required compiling 400 times!

Gonzalo Larralde (@gonzalolarralde) merged changes to specify the linker for Android ARMv7 targets.

Proposals in review

SE-0158: Package Manager Manifest API Redesign by Ankit Aggarwal is under review.

This is a proposal for redesigning the Package.swift manifest APIs provided by Swift Package Manager. This proposal only redesigns the existing public APIs and does not add any new functionality; any API to be added for new functionality will happen in separate proposals.

The Package.swift manifest APIs were designed prior to the API Design Guidelines, and their design was not reviewed by the evolution process. Additionally, there are several small areas which can be cleaned up to make the overall API more “Swifty”.

We would like to redesign these APIs as necessary to provide clean, conventions-compliant APIs that we can rely on in the future. Because we anticipate that the user community for the Swift Package Manager will grow considerably in Swift 4, we would like to make these changes now, before more packages are created using the old API.

Mailing lists

Philippe Hausler (@phausler) opened a pull request to fix a build failure for importing NSUInteger as Int. Not terribly interesting, except for Jordan Rose’s comment linking to this mailing list thread about NSUInteger inconsistencies from a month ago about:

I want to draw attention to one of the oddest parts of the Objective-C importer today: NSUInteger. TLDR: NSUInteger is treated differently based on whether it comes from a system framework or a user-provided header file. I think this is silly and that we should treat it consistently everywhere, but I haven’t had time to go collect data to demonstrate that this is a safe change. Would someone like to take that on? […]

Continue reading…

He explains how NSUInteger is commonly used in frameworks like Foundation, how Swift treats its when importing in certain scenarios, and why all of this is problematic. Fascinating read!

Last week Joe Groff started discussions to revisit SE-0083: Remove bridging conversion behavior from dynamic casts.

I’d like to investigate separating Objective-C bridging from the behavior of the as/as?/is operator family again for Swift 4. Last year, I proposed SE–0083, but we deferred the proposal for lack of time to evaluate its impact. As complicating factors, we now have source compatibility with Swift 3 as a requirement, and the id-as-Any work from SE–0116 more or less requires bridging dynamic casts to work. I think we can nonetheless make important improvements in this area in order to simplify the core language and provide more portable behavior across platforms with and without ObjC interop. In retrospect, submitting SE–0083 as an omnibus “fix casting” proposal was a mistake. We can separate out a few smaller subproblems from the overall concept […]

Later in the thread, Joe elaborates on the as operator:

as isn’t generally for type conversion, it’s for type coercion, giving the type checker additional information it can’t infer. If not for the legacy of inducing bridging conversions, as wouldn’t ever have any effect on its own. Having as sometimes be semantically neutral and sometimes introduce behavior compromises that meaning, since you can’t trust that as doesn’t have other side effects. Aside from the bridging conversions, all other conversion operations in the library are handled by initializers, so it would be more consistent to do the same for explicit bridging operations. Ideally, over time, the native Swift data types will be powerful enough, and the Clang importer and overlays comprehensive enough, to reach the point where explicit bridging conversions are rarely necessary to begin with.

There are numerous discussions on a (sub)module system for Swift, continuing from previous weeks and prompted by Robert Widmann’s (@CodaFi_) original proposal draft email. There are a number of different module system proposals floating around now and being debated. You know everything is going great when each email begins with “Sorry for yet another submodule proposal.” 😆 😅 🍿 Anyway, the community seems far from reaching a consensus here.

Finally

And finally — maybe we have too many JSON parsers?