Issue #95 16 Nov 2017
Written by: Brian Gesiak
“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.
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
Mutable. Check the comments on this one for some helpful hints from
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! 😉
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:
A lot of work this week has centered on conditional conformances:
- Doug Gregor merged
a pull request to implement
Equatableusing conditional conformances, for
- 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.
The review period of SE-0187:
Sequence.filterMap(_:) has been accepted
with an additional re-review period of November 15th - 20th, in order to decide
on a new name:
compactMap, or something else entirely.
[T]he core team feels that the central question is whether Swift benefits from overloading
flatMapin this way. There is a reasonable argument that an
Optionalis 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
Optionalor 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
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
selfinstead. This matches an existing restriction for classes, where cross-module initializers must be convenience initializers.
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!
Brian Gesiak sent
an email summarizing the current state of Swift compile time debugging options
-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.
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
-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
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.
I didn’t think you could get “real work” done on an iPad, but this photo gave me paws.