It has been more than a year since I took over curating the Swift Weekly Brief from Jesse.

When Jesse announced that issue 100 would be the Brief’s final issue, I reached out to him, having helped out with the Brief in the past, to take over the project.

Not only did I really care about this project, but I also felt that it would be a shame to lose this resource for all of you… and myself. I happily took over the project (and still feel very fortunate to continue the effort to this day!) and here we are.

I hope to continue the effort for the foreseeable future! That said, keeping up a newsletter is no easy feat and any help is very much appreciated.

I want to thank all of the readers, sponsors and specifically contributors over the last year. You all rock!

Here is to the next year of the Brief! 🏎

Starter tasks

  • SR-9738 [Compiler] Poor error message when calling @dynamicCallable with incorrect parameter types
  • SR-9781 [Compiler] Crash on concrete typealias access through existential metatype
  • SR-9784 [Compiler] Crash on accessing type alias through protocol-type instance
  • SR-9789 [Compiler] Use “pretty” nullability in generated ObjC headers

Podcasts

On Swift Unwrapped, Jesse and JP discuss Key Path Expressions as Functions.

On the Swift Community Podcast, Garric, Chris and myself discuss Scaling A Codeless Open Source Swift Community.

News and community

Johannes Weiss announced Swift 4.2.2 and monthly Swift 4.2.X releases for Linux!

[..] from now on we will be releasing monthly Swift 4.2.x dot versions for Linux over the next few months. That means you can expect Swift 4.2.3 by the end of February 2019, 4.2.4 by the end of March 2019 and so on.

On the Swift.org blog, Andrew Trick wrote about Swift 5’s Exclusivity Enforcement.

Nathan Hawes also wrote on the Swift.org blog, about the sourcekitd Stress Tester.

Apple released the first Xcode 10.2 beta some time ago. The release notes are now available on the website, without having to login to access the PDF anymore!

John McCall’s presentation on Coroutine Representations and ABIs in LLVM is now available!

Joe Groff and Doug Gregor’s presentation on Efficiently Implementing Runtime Metadata is now available as well.

Slava Pestov shared a thread about the ability to Swift compiler to be able to build an Abstract Syntax Tree (AST) Type from a mangled type string stored in the binary’s debug info.

Commits and pull requests

Rintaro Ishizaki merged a pull request that fixes a SourceKit regression in Swift 5 — within about 12 hours after it was reported!

Ankit Aggarwal merged a pull request to automatically add package dependencies using SwiftSyntax and libSwiftPM. 🎉

Suyash Srijan merged a pull request resolves an issue where using a typealias as an argument to @escaping on a generic function inside a protocol would trigger an error diagnostic.

Accepted proposals

SE-0240: Ordered Collection Diffing was accepted with modifications.

The proposal is accepted with modifications, specifically:

  • The algorithm’s semantic guarantees have been weakened to specify that it will produce a difference to get from the self state to the other state, but not guarantee the shortest such difference. The intent is to allow the standard library to provide a balanced algorithm that provides the shortest difference when possible (e.g., for inputs with fewer differences) but won’t exhibit quadratic behavior for large inputs with many differences.
  • The name of the algorithm itself is changed from shortestEditScript(from:) to difference(from:).
  • The name of the collection of differences is changed from OrderedCollectionDifference to CollectionDifference.

Proposals in review

SE-0241: Deprecate String Index Encoded Offsets is under review.

SE-0180 introduced a computed variable and initializer surrounding the concept of an encodedOffset for serialization purposes. Unfortunately, that approach is flawed for its intended purpose and is commonly misused in ways that Swift 5 is more likely to expose. It is too late in the Swift 5.0 release to solve all existing problems, so we propose deprecating encodedOffset and introducing a targeted, semantics-preserving alternative.

Unfortunately, SE-0180’s approach of a single notion of encodedOffset is flawed. A string can be serialized with a choice of encodings, and the offset is therefore encoding-dependent and requires access to the contents of the string to calculate. A comment in SE-0180’s example source mentioned that encodedOffset assumes UTF-16, which happened to be the only encoding used internally by String at the time (for offset purposes).

Furthermore, the majority of uses of encodedOffset in the wild are not following SE-0180’s intended purpose and are sensitive to encoding changes. encodedOffset is frequently misused under the assumption that all Characters are comprised of a single code unit, which is error-prone and Swift 5 might surface the underlying bugs in more situations. It is also sometimes used for mapping Cocoa string indices, which happens to work in Swift 4 but might not in Swift 5, and Foundation already provides better alternatives.

Finally

Swift is hard. Especially if you want it to be.