Welcome to issue 124 of the Weekly Brief! This is my first issue as an author. I have always been amazed by the Swift community and open source.

Three years ago today, Swift was open sourced. What a journey it has been!

A lot has happened in the Swift community and it seems that team wants to finish all the tasks before the New Year - accepting the Result proposal and publishing Swift 5.0 nightly builds.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-8728 [Compiler] Add note about conditional conformance to RandomAccessCollection docs
  • SR-8513 [Compiler] Confusing error messages for interactions between same-name types from different modules

Swift Unwrapped

Jesse and JP explored the famous Result proposal, discussing its pros and cons.

News and community

The Swift Server Work Group had a meeting. Not only did they add new members, but they also discussed some important topics such as Docker updates, Crypto, HTTP Client improvements and more.

Yasuhiro Inami announced SwiftRewriter, a composable Swift code formatter on top of SwiftSyntax.

Bruno Rocha explored how @dynamicMemberLookup Works Internally in Swift (+ Creating Custom Swift Attributes)

Ole Begemann investigated how to split a Swift Sequence into head and tail in Swift 4.2 and why it will break in Swift 5 because of SE-0234.

Amazon has open sourced smoke-framework, a lightweight server-side service framework written in Swift and using SwiftNIO for its networking layer.

Commits and pull requests

Michael Ilseman merged a pull request which allows to access the raw UTF-8 code units backing a String thanks to String.UTF8View.withContiguousStorageIfAvailable hook.

Slava Pestov merged a pull request that fixes converting a metatype to a readable string when the metatype is for a function type with a single tuple type argument. Related to SR-8235.

Joe Groff merged a pull request that provides ABI space for source location info in unconditional casts.

Harlan Haskins merged a pull request that consolidates the functions used to check accessors versus other declarations, and makes sure we check setter access as well as regular declaration access. This also resolves SR-8969.

Accepted proposals

SE-0235: Add Result to the Standard Library was accepted with modifications.

The Core Team acknowledges the call from several reviewers to make a special effort to communicate how we think Result ought to be used in Swift. We absolutely agree that is an important part of adding Result to the language, and we intend to provide this guidance as part of the release.

Although we are revising the proposal again, the Core Team feels that these issues have already received adequate review, and there is no need for a third round of review. Accordingly, SE-0235 has been Accepted with Modifications.

SE-0236: Package Manager Platform Deployment Settings was accepted.

There was a lot of negative feedback about the platform restrictions part of the proposal, so the SwiftPM code owners decided to accept a revised version of the proposal which only handles customization of deployment targets. The topic of platform restrictions for packages can be revisited separately at a later time.

For specifying custom deployment versions, the original proposal mentions that an initializer will be provided. However, since that would be too verbose, a string overload will be provided instead. This makes the API .macOS("10.13") instead of .macOS(MacOSVersion("10.13")).

SE-0238: Package Manager Target Specific Build Settings was accepted.

This is a proposal for adding support for declaring some commonly used target-specific build settings in the Package.swift manifest file. As the name suggests, target-specific build settings are only applied to a particular target. SwiftPM also aims to support cross-target build settings that go across the target boundary and impart certain settings on a target’s dependees, but this proposal is only concerned with the former type of build settings and the latter will be explored with a future proposal.

SE-0237 Introduce withContiguous{Mutable}StorageIfAvailable methods was returned for revision and later accepted with modifications.

The Core Team felt that the use of inout for the closure parameter of withUnsafeMutableBufferPointer(IfSupported) was the best available option, and noted that the library could verify that the UnsafeMutableBufferPointer itself wasn’t directly modified by checking for the expected base address / count after the call. This limits the chance of confusion without resorting to shadowing or excessive overloading of mutating operations.

The two proposed protocols (ContiguousCollection and MutableContiguousCollection) aren’t used in any algorithms within the library. It is not clear that they are important enough to introduce as protocols into the Standard Library at this time. The Core Team would like to consider a revised proposal that does not introduce these protocols.

There are use cases for a Sequence equivalent to the proposed withUnsafeMutableBufferPointerIfSupported, such as initializing a String from a Sequence of UTF-8 code points that are (e.g.) stored in a Data. The Core Team would like to see this addition to the Sequence protocol, which would allow Sequence clients to optimize for the contiguously-stored case without requiring a new protocol, much as the proposal already allows MutableCollection clients to optimize for the contiguously-stored mutable case.

The revised proposal shows the changes, which are:

  • Sequence will have a new (defaulted) requirement withContiguousStorageIfAvailable, and
  • MutableCollection will have a new (defaulted) requirement withContiguousMutableStorageIfAvailable.

Swift Forums

Amazon recently introduced the Lambda Runtime API to use with any programming language. Ted Kremenek agrees that this is a big step for the Swift on the Server ecosystem.

Async/Await is not yet implemented, but there’s already a few of ideas how to improve it by adding cancellation abilities.

The motivation is to provide a consistent and simple API to cancel asynchronous tasks. My theory (seemingly shared by some) is that supporting cancellation is too much trouble for many programmers, because it is a bit involved and the app may still basically work without it. But performance will likely suffer. With this proposal cancellation becomes a simple task so is much more likely to be implemented by app developers.

The SwiftNIO team wants to change the TLS implementation used by swift-nio-ssl.

We propose to change swift-nio-ssl to stop linking against the system copy of libssl, and instead to provide a vendored copy of BoringSSL. This change would come with a number of subtle runtime behavioural changes, as well as a number of substantially more disruptive changes around application distribution and OS behavior.

The proposed change would drop support for OpenSSL and LibreSSL. The reasoning for this choice is discussed later in the proposal, and is not necessarily mandatory.

Note that for Apple platforms the recommended TLS solution will still be to use swift-nio-transport-services.

Last week, JP Simard wrote how slow SwiftSyntax is. The Swift team has heard it.

Providing direct access to the parser speeds up SwiftSyntax 8x, and it becomes 2x faster than the legacy sourcekitd syntactic request

We all know Mattt’s obsession of Strings, this time pitching Unicode Named Character Escape Sequence.

This proposal adds a new \N{name} escape sequence to Swift string literals, where name is the name of a Unicode character.

Each Unicode character is assigned a unique code point, a number between U+0000 — U+10FFFF, and a name, consisting of uppercase letters (A–Z), digits (0–9), hyphens, and spaces. For example, the Unicode character for the letter “A” used in English has the code point U+0041 and the name LATIN CAPITAL LETTER A. The term scalar value defines the subset of Unicode code points that aren’t surrogate pairs.

In Swift, a string literal may include a character directly (“A”) or using the \u{n} escape sequence, where n is a 1–8 digit hexadecimal number corresponding to the scalar value ("\u{0041}"). A string literal may also include character by interpolation (let letterA = "\u{0041}"; "\(letterA)").

A discussion has arisen about KeyPaths for Tuples in Swift 5.

.. finding out that \SomeType.aTuple.0 does not work ..

I think this would be a great starter project. The runtime ABI for keypaths should not need any modification to handle tuple components, so there’s no rush to implement this. There’s an ABI document that describes the layout of key path objects; the details are somewhat out of date, but the high level structure is the same

Very interesting discussion about Diagnostics and Type Inference after ABI stability.

Two things I really wish would improve are diagnostics and type inference, in particular when it comes to closures and generics. (I’m beginning to accept the limitations on protocols with associated types).

  1. What would be the process to fix such basic annoyances?
  2. Was the focus on ABI stability the main reason for why these issues still exist?
  3. What will be the Swift evolution focus after ABI stability?

Finally

Can we write poetry and haikus about Swift? Yes we can!