Let me start with some very exciting news - our Swift Weekly Brief has been translated into the Chinese language. You can explore translations here. I am thrilled to share this with all of you as I truly believe that reaching more people from around the world who can make an impressive contribution to our community is our way to broaden horizons leading to new inventions.

Meanwhile, Apple hosted its ‘Unleashed’ event and announced some new impressive hardware, satisfying everyone’s taste. Kids will soon be asking Santa for new AirPods and a colorful HomePod Mini to put under Christmas trees later this year, and professional artists are enthusiastic about new powerful MacBook Pros with Apple’s new chips, either the M1 Pro or M1 Max, with four-wheel-drive versions of the M1 chip they presented last fall. Let me know your thoughts about these new machines. Personally, I am looking forward to the 14-inch desktop as it perfectly fits my needs.

Just a kind reminder that we have various opportunities for sponsorship to help us run this project. You can always find more info about the options here. Also, I would like to give a shout-out to our current sponsors - we are grateful and appreciate your support.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

SR-15312 [Swift-DocC] Add ‘version’ command to docc command line tool

SR-15313 [Swift-DocC] Primary tutorial navigation dropdown fails to bold the current tutorial when browser URL is not lowercased

News and community

Franklin Schrans announced Swift-DocC will be open sourced.

Marin Todorov finally revealed his work on Swift Markdown.

Federico Zanetello wrote a blog post explaining @warn_unqualified_access.

Dave DeLong explained how to simplify backwards compatibility in Swift.

Documentation for Swift-DocC is now on Swift.org (using Swift-DocC!).

Proposals in review

SE-0325: Additional Package Plugin APIs is under review.

SE-0303 introduced the ability to define build tool plugins in SwiftPM, allowing custom tools to be invoked while building a package. In support of this, SE-0303 introduced a minimal initial API through which plugins can access information about the target for which they are invoked.

This proposal extends the plugin API to provide more context, including a richer representation of the package graph. This is in preparation for supporting new kinds of plugins in the future.

Swift Forums

Nuri Amari pitched a proposal to improve ClangImporter diagnostics.

We would like to propose improvements to the ClangImporter to provide more detailed diagnostics when an entity cannot be imported from C or Objective-C. As it stands, when the ClangImporter fails to import an entity (function, type, macro, etc.) either entirely or partially, failure is largely silent. The current Swift compilation errors present largely as if the entity was never defined at all.

Frederick Kellison-Linn pitched an idea to generalize keypath-to-function conversions.

This proposal introduces the ability to use the key path expression \Root.value wherever functions of (Root) -> Value are allowed.

Swift-evolution thread: Key Path Expressions as Functions

Patrick Pijnappel pitched a proposal to implement exhaustive pattern matching for non-open classes.

Since we now make the distinction between open and non-open classes, it seems we should be able to make non-open class hierarchies exhaustively matchable. This would be a nice win for compile-time checks in the face of adding a new subclass, without any added syntax.

Guillaume Lessard pitched improvements to pointer usability.

This proposal introduces some quality-of-life improvements for UnsafePointer and its Mutable and Raw variants.

  1. Add an API to obtain an UnsafeRawPointer instance that is advanced to a given alignment from its starting point.
  2. Add an API to obtain a pointer to a stored property of an aggregate T, given an UnsafePointer<T>.
  3. Rename the unchecked subscript of Unsafe[Mutable]Pointer to include the argument label unchecked.
  4. Add the ability to compare pointers of any two types.

Pavel Yaskevich pitched a proposal to improve same-type constraint syntax.

As a step toward the goal of improving the UI of generics outlined in Improving the UI of generics, we’d like to propose a couple of improvements that bridge the syntactic gap between protocols and generic types, and hide some of the complexity (both visual and cognitive) of writing same-type constraints on associated types and type parameters of generic types.

Holly Borla started a discussion about easing the learning curve for introducing generic parameters.

Swift’s generics system is highly expressive, but understanding the full generality of protocols with associated types, generic signatures with where clauses, and other generics features is a significant barrier to introducing generics into a Swift project. A major goal of a more approachable generics system is easing the learning curve of abstracting a concrete API into a generic one by improving the ergonomics of writing generic code in Swift. This discussion is to solicit feedback on possible directions toward achieving this goal, and gather other ideas surfaced by the community. Questions, comments, and ideas are all welcome!

Many of the ideas in this post were laid out by @Joe_Groff in Improving the UI of generics.

Nate Cook pitched an idea to implement character classes for String processing.

Declarative String Processing Overview presents regex-powered matching broadly, without details concerning syntax and semantics, leaving clarification to subsequent pitches. Regular Expression Literals presents more details on regex syntax such as delimiters and PCRE-syntax innards, but explicitly excludes discussion of regex semantics. This pitch and discussion aims to address a targeted subset of regex semantics: definitions of character classes. We propose a comprehensive treatment of regex character class semantics in the context of existing and newly proposed API directly on Character and Unicode.Scalar.

Character classes in regular expressions include metacharacters like \d to match a digit, \s to match whitespace, and . to match any character. Individual literal characters can also be thought of as character classes, as they at least match themselves, and, in case-insensitive matching, their case-toggled counterpart. For the purpose of this work, then, we consider a character class to be any part of a regular expression literal that can match an actual component of a string.

Finally

HIG from 1987.

Its pronounced M 1 “ten”.

 Pascal.