Greetings! Hope you’re feeling a little rested from the week off and are ready to absorb Swift news again. There has been some interesting development activity at the main Swift repo over the past two weeks. Plus, two exciting themes have been covered by Swift Unwrapped. Enjoy the issue!

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-6082: Produce a better error message if Swift is run on a system without clang++
  • SR-6102: Improve Sequence.elementsEqual and lexicographicallyPrecedes
  • SR-6154: Add support for LLVM_REVERSE_ITERATION and use it to uncover non-determinism
  • SR-6207: Misleading error for unqualified use of static variable in method

Submit a task by sending a pull request or opening an issue.

Swift Unwrapped

Episode 33: HTTP server v0.1.0: Jesse and JP discuss the first release of the HTTP server library from the Swift Server APIs project.

Episode 34: Floating-Point: JP and Jesse share their thoughts on numeric protocols and types, especially those of the floating point variety.

News and community

Ted Kremenek posted an article discussing the goals, release process, and estimated schedule for Swift 4.1. This release will be a source compatible update to Swift 4.0, but it will not be binary compatible. Swift 4.1 is intended to be released in the first half of 2018.

Andre Videla posted a discussion of how Swift encourages it’s totality. And there’s a discussion on Twitter.

Slava Pestov started an interesting discussion on improvements to type checker performance in non-WMO builds of projects with many classes.

Harlan Haskins gave a great talk about the structure of libSyntax, design decisions behind it, and how to make use of it to analyze, generate, and transform Swift code.

It’s never too much to repeat the basics, especially in Swift. Ennio Masi wrote about popular sorting algorithms in pure Swift. 🤓

If you’re still doubting to use Swift - check these stats and surveys. Swift’s position is stronger and stronger. 💪

The implementation of SE-0185: Synthesizing Equatable and Hashable conformance might go out in “Swift 4.1” in early 2018. 🎉

Commits and pull requests

Greg Titus and Slava Pestov fixed a crash when a statement in an if let referenced a binding defined later, for example if let b = c, c = ....

Greg Spiers implemented the Swift Evolution proposal “Remove ownership keyword support in protocols” to remove support for weak and unowned keywords for property declarations in protocols.

Kacper Harasim fixed SR-6051: Refactoring to expand missing switch cases from switch keyword to provide cursor refactoring, when the cursor is anywhere on switch keyword lets a user to expand missing switch cases into code placeholders.

Pavel Yaskevich merged improvements to mangling: improve handling of the variadic function parameters.

Rintaro Ishizaki opened pull request to fix SR-5869: trailing closure not parsed correctly in if-statement conditional. The deal is: this fix allows users to write conditional statements with functions with trailing closures inside without parentheses. Before if nums.filter ({ $0 % 2 == 0 }).isEmpty {; after if nums.filter { $0 % 2 == 0 }.isEmpty {.

Doug Gregor fixed compiler crash SR-6100: Compilation hangs when catching error with associated value defined inside generic class/struct.

Mark Lacey opened a pull request with an implementation of warning in case of type is spelled as ImplicitlyUnwrappedOptional rather than T!. It seems SE-0054: Abolish ImplicitlyUnwrappedOptional type will get a full implementation soon!

Robert Widmann implemented the pre-proposal CaseEnumerable protocol (derived collection of enum cases).

Huon Wilson opened a pull request that improves Swift Intermediate Language (SIL). Conditional conformances are inching closer and closer.

Tony Allevato opened a pull request with improvements into synthesize of Equatable/Hashable: synthesis for fields/associated values that are tuples where all fields are Equatable/Hashable.

Slava Pestov fixed various regressions against the master branch.


No updates on proposals this week. As always, you can check out the Swift Evolution status page for all the details.

Mailing lists

Xiaodi Wu pitched a draft proposal at [swift-dev] to rename Sequence.elementsEqual.

The current behavior of Sequence.elementsEqual is potentially confusing to users given its name. Having surveyed the alternative solutions to this problem, it is proposed that the method be renamed to Sequence.lexicographicallyEquals.

Xiaodi Wu continued the conversation about rationalizing FloatingPoint conformance to Equatable at [swift-dev].

Regardless of whether or not it is wise for the partial equivalence relation FloatingPoint.== to be deemed as semantically satisfactory for the purposes of Equatable, the fact remains that Swift deliberately ships with such a conformance, and Array.== should not blow up given that explicitly contemplated design decision. This PR resolves that proximal issue.

Max Moiseev started a discussion about introducing a new standard sequence method: Sequence.filteredMap(_:). Here’s the proposal draft.

We propose to deprecate the controversial version of a Sequence.flatMap method and provide the same functionality under a different, and potentially more descriptive, name.

Slava Pestov pitched an idea to deprecate AnyObject method dispatch.

Dynamic dispatch of methods through AnyObject is a source of implementation complexity, has many known bugs which we are not going to fix, and no longer makes sense now in an id-as-Any world; AnyObject is not the ‘common currency’ type for arbitrary Objective-C objects anymore.

I would like to propose we deprecate it as follows:

  • Unconditional warning in Swift 4.1, with a fixit to add an ‘as’ cast to cast the base value to the right type
  • Error in Swift 5 in -swift-version 5 mode

Thoughts? Does anyone actually rely on this feature, instead of just stumbling on it by accident once in a while?


Are you feeling cold? LLVM dragons will warm you.