“The sky is falling! The sky is falling, and Google is forking Swift!”

Fear not, dear reader, Google doesn’t appear to be “forking” the Swift project – no matter what the blowhards on some venture capitalist’s forum board tell you. Instead, Google employees will simply be using google/swift as a staging area for their pull requests to the main apple/swift project. In fact, this week we already saw some incredible contributions from Google engineers, including support for Fuchsia OS!

So while the internet tries to get a rise out of you, just keep reading Swift Weekly Brief to learn what’s really going on in Swift – I promise you it’ll be less melodramatic than what’s “trending” on Twitter. 😏

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

SR-6360: Ever try to type UnsafeMutableRawBufferPointer, but end up writing UnsafeRawMutableBufferPointer instead? It’s a reasonable mistake, and the Swift compiler should inform users that they switched the placement of Raw and Mutable. Check the comments on this one for some helpful hints from Jordan Rose.

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

Swift Unwrapped

Episode 36: Swift Evolution - Current Topics & Proposals: Jesse and JP discuss some recent proposals.

News and community

A team at Google is planning on contriuting to Swift’s lib/Syntax. Alexander Lash writes, “My team is planning to contribute to lib/Syntax - we’re interested in linting, formatting, and refactoring.” No word yet on whether they’re accepting résumés! 😉

John Holdsworth implemented a proof-of-concept for calling Python code from within Swift.

GitHub user @quellish claims that the new Xcode build system was “on average 28% faster with clean builds and 82% faster on incremental builds” when building an open-source application named “V2EX.app”.

Commits and pull requests

Google engineer Zac Bowling has opened a pull request that adds a Fuchsia OS target to the Swift compiler (one of the first pull requests submitted from the google/swift repository). In case you’re keeping track, a comprehensive set of OS target conditionals in Swift now looks like this:

#if os(OSX) || os(iOS) || os(tvOS) || os(watchOS)
// ...
#elseif os(Linux) || os(FreeBSD) || os(PS4) || os(Android) || os(Cygwin) || os(Fuchsia) || os(Haiku)
// ...
#endif

A lot of work this week has centered on conditional conformances:

  • Doug Gregor merged a pull request to implement Equatable using conditional conformances, for Optional, Array, and Dictionary.
  • Ben Cohen opened a work-in-progress pull request that demonstrates just how much boilerplate can be eliminated from the Swift standard library thanks to conditional conformances.
  • Huon Wilson merged changes to lib/IRGen that allow Swift to produce LLVM IR to represent conditional conformances.

Slava Pestov is going wild reducing Swift compilation times and improving runtime performance. He opened a draft pull request with what Joe Groff calls “a pretty significant optimization for unspecialized Swift code,” as well as a work-in-progress pull request that he notes will crack down on some redundant validation the Swift compiler performs.

Ankit Aggarwal opened a pull request that allows Swift package manager to build projects with the thread sanitizer enabled.

Alper Cugun fixed one of the starter tasks mentioned in last week’s issue.

Many people (myself included) have tried to refactor Swift’s Python build-script. Thankfully, Apple’s Ross Bayer has picked up the mantle and opened a pull request.

Accepted proposals

The review period of SE-0187: Introduce Sequence.filterMap(_:) has been accepted with an additional re-review period of November 15th - 20th, in order to decide on a new name: filterMap, compactMap, or something else entirely.

[T]he core team feels that the central question is whether Swift benefits from overloading flatMap in this way. There is a reasonable argument that an Optional is a sort of container, and therefore it makes sense to “flatten” that container into a surrounding container. But Swift has resisted applying that interpretation in its library design; for example, you cannot directly iterate an Optional or append its contents to an Array. In general, we feel that using different operations for working with Optionals tends to make code easier to both write and understand, especially given the existence of implicit optional promotion, which we cannot eliminate or easily suppress based on the context. On reflection, we think it was a mistake to use the same name in the first place, and there is no better time to fix a mistake than now.

Proposals in review

The review of SE-0189: Restrict Cross-module Struct Initializers has begun and runs through November 21st, 2017.

Adding a property to a public struct in Swift ought to not be a source-breaking change. However, a client in another target can currently extend a struct with a new initializer that directly initializes the struct’s fields. This proposal forbids that, requiring any cross-target initializers to use self.init(...) or assign to self instead. This matches an existing restriction for classes, where cross-module initializers must be convenience initializers.

Mailing lists

Nicole Jacque is seeking volunteers to join a workgroup that aims to “discuss and create a plan for the structure for the Discourse-based forum.” If you have ideas for how online discussions of Swift should take place, please consider volunteering!

Chris Lattner pitched adding user-defined dynamically “callable” types, as part of a series of ideas he has around helping Swift interoperate with dynamic languages such as Python.

Brian Gesiak sent an email summarizing the current state of Swift compile time debugging options such as -debug-time-function-bodies, and asked whether anyone had suggestions for future work in this area. He also opened a pull request to fix an issue he mentioned in the email.

Joe Groff sent an email summarizing how the compiler generates type metadata records, and what implications that has for ABI stability. His email also suggests areas to change.

Joe Groff proposed generalizing the nominal type descriptor data emitted as part of Swift modules’ type metadata, into something he calls “context descriptors.”

Following up on his pull request adding a representation for coroutines in SIL, which last week’s issue of the weekly covered, John McCall sent a proposal for how to represent coroutine types in the Swift AST. His proposal hints at how coroutines will be gradually introduced into Swift’s syntax:

Only special kinds of declarations can be coroutines. In the first stage, that will exclusively be read/modify accessors; eventually we will add generators, but maybe not in Swift 5.

Last week’s issue of the weekly mentioned that Erik Eckstein proposed deprecating the -Ounchecked Swift compiler option. That conversation pivoted into a discussion on whether compiler flags are subject to the Swift Evolution process of community review. This week, Ted Kremenek weighed in to make the case that they are in some cases, and this is one such case. Sounds like we may see a proposal to remove -Ounchecked soon – the first Swift Evolution proposal related to compiler flags.

Swift is capable of running on many platforms outside of just macOS and Linux, but those are the only platforms that are built and tested by the Swift project’s continuous integration bots. Back in September 2016, Ted Kremenek mentioned that support for other platforms would be added, and the clearest estimate of when that was provided on the mailing list was “soon”. This week, Ted mentioned that the feature was tentatively planned for December 2017, but no official announcement has yet been made.

Finally

I didn’t think you could get “real work” done on an iPad, but this photo gave me paws.