Issue #53 19 Jan 2017
Written by: Jesse Squires
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.
Written for students and professionals, the 2nd edition of Swift Algorithms & Data Structures blends modern code, illustrations and computer science to help you pass the interview or build your next app. Revised and updated for Swift 3.0, we’ve recently expanded our shipping options to include more than 70 countries. Use coupon code JESSE at checkout to receive a 20% discount!
- SR-3625: [Swift Package Manager] Make
Processclass thread safe
- SR-3455: [Compiler] Evaluation and validation of build conditions should be separate
- SR-3343: [Standard library] Investigate
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.
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
Chris Eidhof opened a pull request on swift-evolution with an initial draft of his generic subscripts proposal.
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.
As mentioned above, Nicole Jacque sent an email announcing the final merge from
As outlined in Ted’s Swift 3.1 Release Process blog post, for the past month, we’ve been periodically merging
swift-3.1-branchbranch. We will be doing one final merge of master to the
swift-3.1-branchon 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-branchbranch 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-branchwill 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
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
Equatablewhen 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
Sequence? Instead of a
combinefunction 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).
And finally — Swift custom operator ideas?