Welcome to the weekly! As of Tuesday, January 17 master branch development has officially switched to Swift 4.0. This marked the last periodic merge of master into the swift-3.1-branch branch. Anything else going into Swift 3.1 will now require approval from our new Swift overlord, Ted Kremenek. 😄 I suppose this means we’re officially commencing Swift 4 Phase 1.

Starter tasks

  • SR-3625: [Swift Package Manager] Make Process class thread safe
  • SR-3455: [Compiler] Evaluation and validation of build conditions should be separate
  • SR-3343: [Standard library] Investigate Array canaries for withUnsafe* operations

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

News and community

Hopefully everyone has had time to absorb last week’s news that Chris Lattner will be leaving Apple. Nothing has changed, right?! 😄 Lattner was interviewed by MacRumors where he elaborated a bit more on his decision. There are no conspiracy theories here. After 16 years of working on developer tools, wouldn’t you be ready for something new too? Remember, Lattner also started and left LLVM, a project that continues to thrive.

The Accidental Tech Podcast also interviewed Chris Lattner in their latest episode. It’s great and definitely worth a listen!

In cased you missed it back in December or just need a refresher, there’s an official blog post on the Swift 3.1 Release Process.

Commits and pull requests

Karl Weinmeister (@kweinmeister) sent a pull request that implements and tests EnergyFormatter in corelibs-foundation.

Hugh Bellamy (@hughbe) ported swift-demangle to Windows.

Matthew Carroll (@matthewcarroll) submitted a fix for starter bug SR-2475, which adds a diagnostic that warns when an unlabeled parameter follows a variadic parameter.

Arthur Sabintsev (@ArtSabintsev) implemented XCTAssertNoThrow in the SDK overlays for Swift and also add support for this in corelibs-xctest.

Chris Eidhof opened a pull request on swift-evolution with an initial draft of his generic subscripts proposal.

Proposal SE-0080: Failable Numeric Conversion Initializers has officially been marked as implemented for Swift 3.1.

Proposals

Max Moiseev (@moiseev) sent an email regarding the status of proposal SE-0104: Protocol-oriented integers, which was accepted for Swift 3 but not completed in time. This second draft has been updated for the current state of Swift and is being discussed on the mailing list.

Back in June 2016 we discussed the new design of the integer types for the standard library. It even resulted in acceptance of SE-0104 for Swift 3. Unfortunately we were not able to implement it in time for the release.

But it was not forgotten, although, as time went by, a few changes needed to be made in order to reflect the current state of the language. Without further introduction, please welcome the refined proposal to make integers in Swift more suitable for generic programming.

Available in this gist.

There is a fancy new status page! Kyle Murray (@krilnon) built the new status page and wrote a blog post announcing the changes. It seems like he will also review proposal pull requests, as stated in the newly added CONTRIBUTING.md.

To help make sense of it all, the status page has several ways to navigate through the list of proposals. You can search for specific authors, review managers, and topics by keyword. You can narrow the list to show only the proposals that were implemented in a particular version of Swift.

The new site looks great! You can search based on proposal metadata but not proposal contents. I suppose this mostly replaces my swift-proposal-analyzer project. 😅 Sherlocked!

Mailing lists

As mentioned above, Nicole Jacque sent an email announcing the final merge from master:

As outlined in Ted’s Swift 3.1 Release Process blog post, for the past month, we’ve been periodically merging master to the swift-3.1-branch branch. We will be doing one final merge of master to the swift-3.1-branch on January 17 at noon (Pacific). Note that we’ve pushed this back a day due to the MLK Jr. Day holiday. Any changes landed after that time will require approval via a pull request against the swift-3.1-branch branch in order to include them in the Swift 3.1 release. After this final merge, development on master will be targeted for Swift 4.

Snapshots of the swift-3.1-branch will be made available on the downloads page. Snapshots will be made available daily, if all package generation CI tests are passing.

Adam Shin started a discussion on equatability for enums with associated values, proposing that Swift add support for enum values with Equatable associated types be automatically Equatable too.

When using enums with associated values, it’s often necessary to check for equality between two enum objects in some way. That can lead to boilerplate […] which results in code duplication and opens the door to potential logic errors.

Instead, what if enums with associated values were automatically Equatable when all their associated values were Equatable? That would remove the need for such boilerplate code.

Chris Eidhof proposed adding a new version of reduce to the standard library:

How does everyone feel about adding a second version of reduce to Sequence? Instead of a combine function that’s of type (A, Element) -> A, it would be (inout A, Element) -> (). This way, we can write nice functionals algorithms, but have the benefits of inout (mutation within the function, and hopefully some copy eliminations).

Finally

And finally — Swift custom operator ideas?