It has been a while! The previous issue was beautifully crafted by Kristaps Grinbergs. Thanks again so much for that!

With all the heat (in Europe, at least…) I hope you’re keeping it cool.

Starter tasks

• SR-11148 [Compiler] Separate do and while blocks generate error from legacy diagnostic
• SR-11159 [Compiler] Typechecker crash on overloaded enum case

News and community

SwiftNIO 2.4.0 shipped, containing an important fix for everybody using HTTP/1 + upgraders, for example WebSocket. You can read the analysis of the issue here.

Kevin Sweeney shared the release of Swift 5.0.2 for Linux.

Edd Wilder-James shared an update on expanding Tensorflow in the open, announcing a special interest group for Multi-Level Intermediate Representation (MLIR), an intermediate representation and compiler framework.

Tom Doron shared meeting notes of the Swift on the server workgroup meeting on July 11th.

Johannes Weiss shared an API-breakage checker has been added to the SwiftNIO repository.

Doug Gregor once more asked to include projects to the Source Compatibility Suite, which is used to detect breaking changes.

Commits and pull requests

Armen Mkrtchian merged a pull request with non-ASCII String case-conversion benchmarks that uncovered optimization opportunities for ASCII strings.

David Smith merged a pull request that implements those optimizations uncovered by Armen! 🏎

Erik Eckstein merged a pull request that makes Swift traps more user-friendly. By encoding the error message in the DWARF line table, you’ll see the message in .dSYM-symbolicated backtraces and crash reports, without strings leaking in your binaries.

Proposals in review

SE-0261: Identifiable Protocol is under review.

This proposal introduces an Identifiable protocol, a general concept that is broadly useful — for diff algorithms, user interface libraries, and other generic code — to correlate snapshots of the state of an entity in order to identify changes. It is a fundamental notion that deserves representation in the standard library.

SE-0262: Demangle Function is under review.

Introduce a new standard library function, demangle, that takes a mangled Swift symbol, like $sSS7cStringSSSPys4Int8VG_tcfC, and output the human readable Swift symbol, like Swift.String.init(cString: Swift.UnsafePointer<Swift.Int8>) -> Swift.String.

Currently in Swift, if a user is given an unreadable mangled symbol, they’re most likely to use the swift-demangle tool to get the demangled version. However, this is a little awkward when you want to demangle a symbol in-process in Swift. One could create a new Process from Foundation and set it up to launch a new process within the process to use swift-demangle, but the standard library can do better and easier.

Swift Forums

Delisa Mason pitched a proposal to introduce a cleanup callback for fatal Swift errors.

In the event of a fatal error caused by Swift code, there is no direct way to get the error message and context from Swift without out-of-process log parsing. Fatal errors “fall through” to signal handlers at which point the crash context is lost. The goal of this proposal is to provide a native Swift cleanup callback for fatal errors without the complexity of signal handlers nor allowing attempted recovery. This context could be written to disk or logged in a custom format or aggregated for later analysis.

Soroush Khanlou pitched a proposal to require parameter names when referencing to functions.

Some of you may remember SE-0220 my proposal that added the count(where:) function to sequences. This proposal was ultimately accepted in time for Swift 5, but sadly had to be reverted because it was causing issues with the type checker.

The issue was that when you reference count, in an expression like myArray.count * 5, you could be referring to the count property, with type Int, or the count(where:) function, which has type ((Element) -> Bool) -> Int, which you can refer to in shorthand as count. When Swift tries to resolve what version of the * function to use, it has to run through a lot more potential implementations, which explode combinatorially as you increase the number of operators in the expression.

I’ve thought about this problem for a while and chatted with a few folks about the issue, and I think the simplest path forward to solve this is to require parameter names when referencing functions.

Iggy Drougge pitched a proposal to add compilation conditions for word size.

A lot of code written to support more than one platform contains #if arch() conditions to handle differences between 32-bit or 64-bit platforms or little and big endian CPUs. This may turn into long statements like #if arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le), enumerating every (currently) supported architecture which must be handled by that #if ... #endif clause.

Jari Koopman shared a proposal to implement a Swift Prometheus implementation.

Prometheus is one of the most widely used libraries for metrics in the serverside world. SwiftPrometheus is a client side implementation in Swift, with the ability to use it both connected to & separately from swift-metrics.

With Prometheus being one of the most widely used metric reporting tools, it’s a buildstone that can not be left out in a serverside ecosystem. This package is created for everyone to use & build upon for their metric reporting.

Finally

Your argument is… valid?!