Issue #60 09 Mar 2017
Written by: Jesse Squires
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.
Hello, it’s Paul Hudson again, still with Hacking with Swift, and still helping to support this awesome newsletter. After you’ve finished reading, why not download my Natural Swift video? It’s 75 minutes of pure Swift goodness, and completely free.
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.
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
Commits and pull requests
Slava Pestov (@slava_pestov) fixed a conformance lookup issue. When substituting a type like
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. (
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!
Proposals in review
This is a proposal for redesigning the
Package.swiftmanifest 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.
Package.swiftmanifest 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.
Philippe Hausler (@phausler) opened a pull request to fix a build failure for importing
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:
NSUIntegeris 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? […]
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!
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
asisn’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,
aswouldn’t ever have any effect on its own. Having
assometimes be semantically neutral and sometimes introduce behavior compromises that meaning, since you can’t trust that
asdoesn’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.
And finally — maybe we have too many JSON parsers?