Issue #108 03 May 2018
Written by: Bas Broek
Another two weeks have passed since the last issue, and its now May. How time flies! WWDC is creeping up, while the Swift team is still hard at work on Swift 4.2 and Swift 5.
Starter tasks
- SR-7559 [Package Manager] Building
swiftpm
requiresrsync
, and crashes with an obscure message if not found
Submit a task by sending a pull request or opening an issue.
Swift Unwrapped
In episode 55, Jesse and JP discuss SE-0202, Random Unification.
In episode 56, Jesse and JP discuss SE-0206, Hashable Enhancements.
News and community
Paul Hudson created a website to show a nice overview of what’s new in Swift, browsable by version!
Mark Lacey wrote a blog post on the official Swift blog, dicussing the reimplementation of Implicitly Unwrapped Optionals.
Google announced Tensorflow for Swift. To learn more about it, check out the Design Overview.
Commits and pull requests
Michael Ilseman merged a pull request that removes some @inline
annotations, speeding up the compiler.
Doug Gregor merged a pull request that lays the groudwork to eliminate SubstitutionList
, the old representation for a mapping of generic parameters to concrete types. To learn more about this, check out this Twitter thread.
Pavel Yaskevich merged a pull request that improves exhaustiveness checking in switch
es.
Accepted proposals
SE-0202: Random Unification was accepted with revisions.
The core team has accepted this proposal, with the following revisions:
The method to get a random element from a collection should be named
Collection.randomElement() -> Element?
Since not all platforms will be able to provide an implementation of random that’s a cryptographically secure source of randomness, and that different platforms and users have different priorities, the decision of exactly which implementation to use for the default random number generator will be left to that platform’s implementation of Swift.
The core team decided to keep the proposal’s use of static methods.
The random number generator argument should be taken
inout
.
SE-0207: Add a containsOnly
algorithm to Sequence
was accepted with revisions
The core team accepted one of the two proposed Sequence extensions, with a different name than was proposed:
Proposals in review
SE-0210: Add an offset(of:)
method to MemoryLayout
is under review.
This proposal introduces the ability for Swift code to query the in-memory layout of stored properties in aggregates using key paths. Like the
offsetof
macro in C,MemoryLayout<T>.offset(of:)
returns the distance in bytes between a pointer to a value and a pointer to one of its fields.
SE-0211: Add Unicode Properties to Unicode.Scalar
is under review.
We propose adding a number of properties to the
Unicode.Scalar
type to support both common and advanced text processing use cases, filling in a number of gaps in Swift’s text support compared to other programming languages.The Swift String type, and related types like
Character
andUnicode.Scalar
, provide very rich support for Unicode-correct operations. String comparisons are normalized, grapheme cluster boundaries are automatically detected, and string contents can be easily accessed in terms of grapheme clusters, code points, and UTF-8 and -16 code units.However, when drilling down to lower levels, like individual code points (i.e.,
Unicode.Scalar
elements), the current APIs are missing a number of fundamental features available in other programming languages.Unicode.Scalar
lacks the ability to ask whether a scalar is upper/lowercase or what its upper/lowercase mapping is, if it is a whitespace character, and so forth.
SE-0212: Compiler Version Directive is under review.
This proposal introduces a
compiler
directive that is syntactically equivalent to the#if swift
version check but checks against the version of the compiler, regardless of which compatibility mode it’s currently running in.The
#if swift
check allows conditionally compiling code depending on the version of the language. Prior to Swift 4, the version of the compiler and the language were one and the same. But since Swift 4, the compiler can run in a compatibility mode for previous Swift versions, introducing an new version dimension. To support code across multiple compiler versions and compatibility modes, extra language versions are regularly introduced to represent old language versions running under compatibility mode.
Swift Forums
Soroush Khanlou pitched a proposal to add count(where:)
to Sequence
.
While Swift’s
Sequence
models brings a lot of niceties that we didn’t have access to in Objective-C, like map and filter, there are other useful operations onSequence
s 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.
You can read the proposal here.
Doug Gregor wrote a request for discussion regarding an issue with non-escaping closure parameters can escape through Objective-C.
The easiest way to see the problem is to define an
@objc
protocol with a closure-taking method:
And then implement that protocol in Objective-C
[..] I see a couple of potential solutions here, which aren’t mutually exclusive:
- Implicitly use
withoutActuallyEscaping
when calling an@objc
API from Swift- Warn about non-escaping closure parameters in
@objc
entry points that can be implemented in Objective-CThoughts?
Finally
Lets open the wound on access control again, shall we? 😂