The fourth beta of Xcode 9/Swift 4 was released this week, which included support for Swift static libraries. Proposals are winding down with only revisions to SE-0104 still in review. And everybody’s favorite topic — the Swift Evolution process — was discussed on the swift-evolution mailing lists. 😄

Swift Unwrapped

This week in Episode 21, we dive into some of the recent proposals, including SE-0180, SE-0181, SE-0182, SE-0183.

News and community

Xcode 9 beta 4 was released. (Release notes here.) The big news is that the standard and the new build system both support Swift static libraries now. Thanks Daniel!

Jordan Rose’s documentation on Swift, LLVM, and LLDV branching merged is now available in at docs/Branches.md.

Not entirely related to Swift, but three new Darwin lib mirrors have appeared under the Apple GitHub organization over the past few weeks: darwin-xnu (Darwin Kernel), darwin-libplatform (Darwin Platform Library), and darwin-libpthread (Darwin PThread Library). These were previously only available at opensource.apple.com.

Also unrelated, but did you know that you can write Go in Xcode?

Commits and pull requests

Doug Gregor merged changes to enable recursive protocol constraints (SE-0157). “With this change, type-checking the standard library is 4% faster than it was prior to this patch series…”

Michael Ilseman and Dave Abrahams implemented changes to give Substring its own views. “Substring now has distinct views inside of it. String’s view’s SubSequences are the same as Substring’s respective views, lending a consistent API that also encourages/enforces thinking about slices holding onto memory.”

Maxim Moiseev implemented the updates to proposal SE-0104.

Bartek Chlebek added Codable conformances to CGPoint, CGSize, and CGRect in corelibs-foundation.

@practicalswift added seven new compiler crashers. (43, 44, 45, 46, 47, 48, 49)

Accepted proposals

SE-0183: Substring performance affordances was accepted.

As expected, feedback was light but positive. Thanks to Ben Cohen for driving this effort forward.

Proposals in review

The fourth revision of SE-0104: Protocol-oriented integers is under review. You can find the diff here.

Following feedback during the 4.0 preview, a handful of minor amendments have been suggested to SE-104: Protocol-oriented integers that the core team feels are important to include into 4.0 as they have an impact on source stability.

Mailing lists

The discussion for the fourth review of SE-0104: Protocol-oriented integers got derailed into yet another meta-discussion about the swift-evolution process itself. As always, Chris Lattner provided a kind and insightful response to the concerns:

This is a great thing to discuss, and I don’t think that there is an iron-clad answer. Keeping swift-evolution effective is a complex problem, because it is highly multi-dimentional space to optimize in. We want to engage the community, encourage people to participate, allow people to push Swift in new directions (when that makes sense) and keep discussions productive and humane. All of this serves a meta goal of harnessing the folks who participate on swift-evolution to make Swift the best language possible.

The constraints are obvious: on most non-trivial topics, there will be some disagreement, so not everyone can be happy. There is only so much engineering time to build cool new things, so it has to be prioritized and divvied up somehow. As you say, it is impossible to make perfect decisions up front, so revisions and iteration are inevitable. Constraints like source and (looming) ABI stability restrict the kinds of changes that can be made. This is made all the more complicated by the fact that a lot of the tradeoffs made are necessarily judgement calls (and occasionally quite subjective), and decisions must be made with imperfect information (e.g. how long it will take to develop a feature). I think it is truly fantastic how engaged and productive swift-evolution is, particularly considering these challenges.

I don’t know how Swift 5 will go, but I would guess that it will be similar to the Swift 4 cycle, but will include changes made by learning from it. If so, it means that Ted will define the overarching themes for the release, to help prioritize effort. This is because currently Apple is paying for the majority of the engineering and they have a completely rationale right to determine how they spend that engineering time. In addition to the major themes, there will be other areas of focus as well (some of which won’t impact swift-evolution, like improvements to build times, performance, and stability).

Development will continue for some period of time, building out new things and a “feature complete” point will be reached. At this point, major changes will be restricted in an effort to stabilize and reduce risk for the release. This doesn’t mean that “no changes” will be made, but as the release grinds inexorably towards its final GM build the scope of changes will be restricted more and more. This is an interesting challenge given that “Beta 1” is usually the first release that goes out to the really broad Swift community, so it is the release that generates the most insight on where the changes have hit their mark or where they have missed. It is incredibly important to enable a feedback loop between folks using the early Swift toolchain builds and the betas so that we can refine and improve things to be the best possible.

Given that we’re very very late in the Swift 4 cycle, this is why Ben is guiding feedback in a certain narrow way (and why Xiaodi is helping to reinforce that guidance). As he says, there are certain changes that just can’t be made rationally at this late stage, because big or risky changes require an iteration and feedback cycle, and there isn’t time for it.

Going forward, we’ll all try to communicate what sorts of changes are appropriate at a given time. That said, we can’t make a perfect prediction and guarantee an absolute schedule. I know this can be frustrating, but it is simply the nature of having to make decisions without perfect information.

Morten Bek Ditlevsen started a thread to ask about exposing _JSONEncoder and _JSONDecoder, which are private components used for the new Codable protocol in the standard library. If you read Greg Heo’s article on this, you’ll remember that the new Swift encoders and decoders just use NSJSONSerialization internally. Itai Ferber noted that this may change in the future:

This is something we’ve considered adding and may do so in the future — however, this will require additional API review and will not make it in time for the Swift 4.0 release. The usage of JSONSerialization as the serialization backend is a current implementation detail, and may change in future releases; it would, for instance, be more efficient to read/write JSON as we encode/decode, instead of trying to collect the entire object graph before performing the next step.

We could also introduce something like a general StructureEncoder/StructureDecoder which performs this conversion, as this might be useful outside of just JSON. (For instance, PropertyListEncoder/PropertyListDecoder currently do something similar.)

So yes, this is under consideration for future API. :)

Finally

And finally — You say “missing retain bugs”…. 😂