If you haven’t heard about it yet, we’ve been seeing a start to async / await in Swift these past two weeks. While this will take a lot more time before we can expect to see this land in Swift, it is an exciting thing to see. 🏎

Interested in sponsoring Swift Weekly Brief? Learn more here.

Podcasts

John Sundell discusses what’s new in Swift 5.3 with JP Simard.

Starter tasks

  • SR-13237 [Compiler] Remove ModuleDecl::isClangModule()
  • SR-13245 [Compiler] Refactor construction of ModuleDecl::ImportFilters to use new initializer list constructor
  • SR-13246 [Compiler] Refactor manual size calculations to use totalSizeToAlloc

News and community

Kaitlin Mahar, Simon Pilkington, and Todd Varland join the Swift Server Workgroup.

Commits and pull requests

Doug Gregor merged a pull request that adds async to the Swift type system.

Doug Gregor opened a pull request stubbing out an experimental concurrency support library.

Ben Langmuir merged [a pull request]https://github.com/apple/sourcekit-lsp/pull/298) that contains a big speedup for code-completion in SourceKit-LSP.

Nate Cook merged a pull request, allowing for autocompletion in the Swift argument parser.

Accepted proposals

SE-0286: Forward-scan matching for trailing closures was accepted with modifications.

Initial feedback on the review was generally positive on the concept, but several reviewers were troubled by the potential for source incompatibilities. The proposal author investigated options for maintaining compatibility better, and when they seemed to work out, the core team elected to amend the proposal during review. The community then expressed strong support for the revised proposal, and the feeling among reviewers was that there was no need for a second review. The core team discussed this and agreed. Accordingly, the revised proposal is accepted with modifications.

SE-0285: Ease the transition to concise magic file strings was accepted.

The feedback was generally positive, and to address the concern around which variants of #file library authors should use the proposal was modified to include Swift API Design Guidelines amendment encouraging library authors to prefer #fileID over alternatives.

SE-0284: Allow Multiple Variadic Parameters in Functions, Subscripts, and Initializers was accepted.

Some reviewers indicated that they would prefer to format code in certain ways to aid with legibility, but the functionality itself was well received. The core team noted that this was an oversight in the original implementation and should have been permitted in the original implementation.

Proposals in review

SE-0286: Forward-scan matching for trailing closures is under review.

SE-0279 “Multiple Trailing Closures” threaded the needle between getting the syntax we wanted for multiple trailing closures without breaking source compatibility. One aspect of that compromise was to extend (rather than replace) the existing rule for matching a trailing closure to a parameter by scanning backward from the end of the parameter list.

However, the backward-scan matching rule makes it hard to write good API that uses trailing closures, especially multiple trailing closures. This proposal replaces the backward scan with a forward scan wherever possible, which is simpler, more in line with normal argument matching in a call, and works better for APIs that support trailing closures (whether single or multiple) and default arguments. This change introduces a minor source break for code involving multiple, defaulted closure parameters, but that source break is staged over multiple Swift versions.

Swift Forums

Karl pitched a proposal for Shared Substrings.

Shared Substrings give us a way to interpret buffers of bytes as unicode text, without allocating new storage exclusively owned by a String object. It would, for example, allow developers to receive data from a file or network connection as an Array<UInt8> or Foundation Data object, and parse that data as text without copying it. Additionally, it gives developers of structured text objects (like URLs) greater control over how they organise their storage.

Mattt pitched a proposal to support non-binary source dependencies in the Swift Package Manager.

Swift Package Manager added support for binary dependencies with SE-0272. This proposal extends that functionality to support non-binary source dependencies as well.

Swift Package Manager requires a source dependency to be hosted in a Git repository with a package manifest located in its root. This can cause problems for projects with a different directory structure or that use a version control system other than Git.

Harshil Shah pitched a proposal for Lazy Filter Subscripts.

In playing around with the standard library’s Sequence types, I noticed an unexpected behaviour.

The current implementation of LazyFilterCollection uses the indices of the base collection as its own, and also forwards any subscripts directly to the base collection.

This means that it is possible to retrieve values via subscripting that shouldn’t exist in the filtered collection:

let evenDigits = Array(0 ..< 10).lazy.filter { $0.isMultiple(of: 2) }
print(evenDigits[3]) // prints 3

And it also means that indices which don’t exist in the filtered collection can be subscripted:

let evenDigits = Array(0 ..< 10).lazy.filter { $0.isMultiple(of: 2) }
print(evenDigits[5])               // prints 5
print(Array(eventDigits[5...]))    // prints [6, 8]

This behaviour isn’t currently documented.

Justin Reusch pitched a proposal to allow Memoization of Swift properties.

Swift has a focus on being fast and efficient. To this goal, the memoization of computed properties would help to speed up some Swift programs relying on computed values (especially expensive ones) by only re-calculating the results when one of the properties they depend on has changed.

Anyone familiar with React and React hooks will know one of the most useful hooks is React’s useMemo, which provides this exact functionality for rendering UIs. While memoization would be broadly applicable to any Swift program, it may be especially helpful for use in SwiftUI, where preventing unnecessary re-renders can help optimize app performance.

Finally

Swift is more than 10 years old, now!