This week in Swift development: the Swift team created several fun new starter tasks, Doug Gregor fixed a nasty bug in Objective-C interop, and the mailing lists were abuzz with several exciting Swift Evolution proposals. Adjust your Apple Watches – it’s “Swift Weekly Brief O’Clock”!

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

• SR-6264: This task is to extract duplicated code in three methods. The methods each check whether a declaration may be used externally based on its access level (public, internal, etc.).
• SR-6272: This task is to add better diagnostics for common numerical conversions. For example, the Swift compiler should be able to suggest a cast for source code that attempts to multiply an Int and a CGFloat.
• SR-6312: To clone the apple/swift family of projects, and to pull in the latest changes to those clones, contributors use a Python script: utils/update-checkout --clone to clone, and just utils/update-checkout to update. This task is to modify utils/update-checkout so that it suggests using --clone if the user attempts to update before cloning.

If you’re looking for a meatier task, you may want to try SR-3423, which would allow enum cases with tuple raw values. In other words, you could make this possible in Swift:

enum Status: (Int, String) {
  case OK = (200, "OK")
  case NotFound = (404, "Not Found")
}

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

News and community

Arek Holko posted a checklist for diagnosing and improving long compile times in Swift projects.

Brian Gesiak continued his Swift compiler series with An Introduction to the Swift Compiler Driver.

Commits and pull requests

Doug Gregor fixed an issue in which Swift’s ClangImporter would use a stale AST cache for properties of Objective-C classes, which affected how declarations would be imported into Swift. This most likely fixes an issue in which -[UIView addGestureRecognizer:] would sometimes be imported as UIView.add(_:).

John McCall added a way to represent coroutines in Swift’s intermediate language, SIL.

Daniel Dunbar opened a pull request that improves the cancellation model in llbuild. Previously, cancelling a build in llbuild would not stop work that was in-flight, but instead merely have those units of work finish normally and then report a “cancelled” status. The change cancels the work, preventing it from completing as it normally would.

Mark Lacey opened a pull request to fix edge cases in which implicitly-unwrapped optional (IUO) usage that was disallowed by SE-0054 was considered valid in Swift 3 and 4. This is a “source-breaking” change for codebases that used syntax that, while being technically invalid in Swift 3 and 4, would not result in errors being emitted by the Swift compiler until now. He also opened a pull request that removes a soon-to-be-disallowed IUO from swift-corelibs-foundation.

Philippe Hausler opened a pull request to update swift-corelibs-foundation with the latest CoreFoundation source code included in macOS High Sierra.

Francis Ricci opened a pull request that allows Objective-C to be imported even on non-Darwin platforms. Although I would imagine almost no developers use an Objective-C runtime outside of Darwin, this does decouple some ClangImporter behavior from its host platform, which seems like a good thing to do.

Proposals in review

The review of SE-0187: Introduce Sequence.filterMap(_:) has begun and runs through November 14th, 2017.

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. […] The name being filterMap(_:) as we believe it best describes the intent of this function. […] Since the old function will still be available (although deprecated) all the existing code will compile, producing a deprecation warning and a fix-it.

The review of SE-0188: Make stdlib index types Hashable begins now and runs through November 14th, 2017.

This proposal would add Hashable conformance to all the index types in the standard library. With that done, [Int], String, and all other standard libary collections would have the same behavior when using subscripts in key paths.

Mailing lists

Tony Parker solicited public feedback on a Foundation-only proposal that has been evaluated internally at Apple. The proposal is for a mechanism to encode and decode JSON keys in order to, for example, automatically deserialize snake_case_keys as camelCaseKeys.

Dave DeLong proposed allowing custom operators to take parameters with default arguments. He also provided an implementation with the proposal.

Ben Cohen pitched eliminating IndexDistance from Collection. He tweeted that it would make writing generic algorithms easier.

Alejandro Alonso proposed adding standard library functions for generating random numbers, as well as for randomizing the order of an array (“shuffling”). The proposal aims to address a pain point in cross-platform Swift development, since different platforms use different randomization functions (arc4random() on Darwin, random() or rand() on Linux, etc.).

Jacob Bandes-Storch re-proposed adding an allCases static property to enums. The proposal was widely popular when it was first proposed for Swift 3, but ultimately deferred. If it’s accepted this time, we may see it in Swift 5.

Discussion of Graydon Hoare’s Swift Evolution proposal draft, which adds a target environment platform condition to the Swift language, continues. The patch proposes adding a #if targetEnvironment(simulator) condition. Replies to the proposal began to discuss what attributes should be available as platform conditions. This week, Graydon pointed out that whether the compilation target was a simulator or not was encoded in the target triple, a decision made recently in LLVM, so discussions of whether it should be encoded at all should be done on the LLVM mailing lists.

Becca Royal-Gordon asked about how she could update her once deferred proposal, SE-0132, which proposes renaming several Sequence and Collection methods such that they follow a consistent naming scheme.

Erik Eckstein proposed deprecating the -Ounchecked compiler option. This optimization mode removes runtime safety checks, and adds additional complexity to the standard library code, which must behave differently at that optimization level.

Rick Ballard responded to questions about SwiftPM’s roadmap for Swift 5.

Kelvin Ma pointed out that Swift has potential to layout some enums using fewer bytes.

Finally

Did you remember to adjust for DST? (That’s “delightful Swift time”, of course.)