Issue #106 05 Apr 2018
Written by: Greg Heo
Lo! The forum posts and pitches fly on by
What rants and revelations there await?
Swift 5 remains a glimmer in the sky
As compactMap arrives to disorientate.
New Xcode versions, filled with all-new fix-its
And random numbers, ascribing golden tickets.
There’s been plenty of news to make developers experience the full range of emotions: Xcode 9.3 with Swift 4.1 made it out of the gate, the WWDC ticket lottery smiled on some and caused gnashing of teeth in others.
Meanwhile, Swift 4.2 and beyond await us. As a reminder, the final merge into the Swift 4.2 branch before the soak period is coming up in two weeks, on April 20.
What’s new in the world of Swift? Read on!
Starter tasks
- SR-7323: SPM can’t handle spaces in path to Xcode
- SR-7307: Warn when a block contains nothing but a defer statement
- SR-7301: Bad fixit suggested for protocol extension implementation for inherited objc protocol
- SR-7292: Swift local refactoring: adding field-wise initializers automatically
- SR-7266:
reversed()
applied multiple times should not nestReversedCollection
into itself
Submit a task by sending a pull request or opening an issue.
Swift Unwrapped
Episode 51 is the long-awaited Part 2 of Doug Gregor and Ben Cohen discussing Swift 4.1.
In Episode 52, JP and Jesse cover two new pitches regarding Swift Package Manager.
News and community
Languages & Runtime manager Ted Kremenek shared photos of some new office decorations over at Swift HQ. 🤖
Chris Lattner announced Swift for TensorFlow, bringing first-class compiler and language support for the machine learning framework. Aside from the post, you can also watch the video announcement presented at the TensorFlow Dev Summit 2018 by Chris and Richard Wei.
try! Swift San Jose was announced, with a focus on Swift Evolution and all the other Swift open source projects.
Commits and pull requests
Greg Titus fixed a compiler crash that happened when a case
statement had both let
and var
bindings for the same name.
Stephen Canon merged a change to how description
and debugDescription
display floating-point values. The diff is a fascinating read into a fast and simple algorithm, and be sure to check out the chart showing the performance gains! 😍
Karoy Lorentey merged his pull request to add conditional conformance to Hashable
in more standard library types. Optionals, arrays, dictionaries, and ranges (among other types) can now participate in synthesized Hashable
conformance.
Mark Lacey landed a change to fix type checking going exponential for tuple literals. One fewer case of Xcode complaining that a type check took too long? ⏱
Michael Ilseman added the new SmallString
type to the standard library. The type is supported on 64-bit architectures and offers optimizations specific for (you guessed it) small strings.
Accepted proposals
SE-0192: Non-Exhaustive Enums is out of re-review and has been accepted with revisions.
This proposal introduces frozen vs non-frozen enumerations, and the final revisions add the new @unknown
attribute.
SE-0201: Package Manager Local Dependencies by Ankit Aggarwal was accepted.
This proposal allows you to declare a package dependency via a local path rather than a remote URL.
Returned proposals
SE-0200: “Raw” mode string literals by John Holdsworth was returned for revision.
This proposal had a ton of discussion in the thread. The two main reasons for returning the proposal for revision were:
- The proposed
r"..."
syntax didn’t fit well with the rest of the language.- The proposal itself leans heavily on regular expressions as a use case for raw string literals… a revised proposal will need additional motivating examples in other domains.
Proposals in review
SE-0202: Random Unification by Alejandro Alonso is just out of review, awaiting results.
This proposal adds random()
static function to numeric types and collections, a shuffled()
method to sequences, as well as a shuffle()
method to mutable collections.
SE-0203: Rename Sequence.elementsEqual by Xiaodi Wu is in review.
This proposal would remove a point of confusion where ==
and elementsEqual(_:)
could return different results.
Having surveyed alternative solutions to this problem, it is proposed that the method be renamed to
Sequence.elementsEqualInIterationOrder
.
SE-0204: Add last(where:) and lastIndex(where:) Methods by Nate Cook is in review.
We already have methods first(where:)
and index(where:)
, and this proposal would add similar methods to search from the end rather than from the beginning.
SE-0206: Hashable Enhancements by Karoy Lorentey and Vincent Esche is in review until April 13.
This proposal introduces a new
Hasher
type representing the standard library’s universal hash function, and it extends theHashable
protocol with a newhash(into:)
requirement that expresses hashing in terms ofHasher
. […] Standardizing on a single, high-quality hash function greatly improves the reliability ofSet
andDictionary
.
SE-0207: Add a containsOnly
algorithm to Sequence
by Ben Cohen is under review.
It is common to want to confirm that every element of a sequence equals a value, or matches a certain criteria. Many implementations of this can be found in use on GitHub. This proposal adds such a method to
Sequence
.
Instead of this:
You’ll be able to do this:
Joe Groff suggested a proposal to add offset(of:)
to MemoryLayout
.
This proposal introduces the ability for Swift code to query the in-memory layout of stored properties in aggregates using key paths.
MemoryLayout<Rect>.offset(of: \.origin.x) // => 0
MemoryLayout<Rect>.offset(of: \.origin.y) // => 8
Swift Forums
Soroush Khanlou pitched an addition to Sequence
to provide count(where:)
:
While Swift’s Sequence models brings a lot of niceties that we didn’t have access to in Objective-C, like
map
andfilter
, there are other useful operations on Sequences that the standard library doesn’t support yet. I’d like to pitch one today:count(where:)
, which counts the number of objects in a Sequence that passes some test.
[1, 2, 3, -1, -2].count(where: { $0 > 0 }) // => 3
Michael Ilseman wrote a pitch for character and string properties. This would add support for some handy computed properties such as isWhitespace
and isAscii
on characters, and helper structs and methods on strings to split lines and words.
Why not reach into string and character properties and do all this yourself? Short answer: Unicode is hard. 😓
[There] is potential harm in developers reaching for these properties to solve common tasks without understanding their deep implications in Unicode. Whenever possible, we believe the best form of harm-reduction is providing more ergonomic APIs with more appropriate semantics for these common tasks.
A few weeks ago, Graydon Hoare posted about the new compiler batch mode that could speed up your Swift compile times. The thread has a lot of real-world results from people trying things out on their own code bases; have a look if you’re interested in what might be coming up in future releases.
O RLY?
Finally: I can’t wait for #error
and #warning
to land in Swift 4.2, but in the meantime at least there’s Swift support for #lolcode
. 😹