Welcome to issue 123 of the Weekly Brief! Although winter is approaching fast, that doesn’t stop the Swift team and community (yet). A lot of discussion has taken place over the last two weeks, and below you’ll find an overview of that.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

• SR-9341 [Tooling] Add tests for update-checkout (Python)
• SR-9373 [Compiler] Clang importer should refuse to import arrays with excessive numbers of elements

News and community

Patrick Balesta wrote a blog post on contributing to the Swift Benchmark Suite!

Daniel Martín wrote a blog post with tips and tricks for contributing to the Swift language!

My talk from try! Swift NYC on Swift’s history, “Taken for Granted”, was posted. Slides can be found here.

Mattt wrote a blog post on how to set up Visual Studio Code for Swift development. This is possible thanks to the Language Server Protocol that Apple has started working on.

JP Simard wrote a blog post about implementing SwiftLint using SwiftSyntax… making it 20x (!) slower.

Commits and pull requests

Michael Ilseman merged a pull request to speed up utf16 Strings!

Accepted proposals

SE-0234: Remove Sequence.SubSequence was accepted.

Review feedback was pretty strongly positive. Several community members voiced their experience that attempting to implement the sub-sequence requirements had been an annoyance to them in the past. No-one seemed to feel that the requirements were actually valuable.

Proposals in review

SE-0237: Introduce Contiguous Collection Protocols is under review.

This proposal introduces two new protocols, ContiguousCollection, and a mutable version MutableContiguousCollection. These protocols will allow generic code to make use of the withUnsafe{Mutable}BufferPointer idiom, as well as provide fast paths in the standard library for adopting types.

SE-0238: Package Manager Target Specific Build Settings is under review.

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 currently has little facility for customizing how the build tools (compilers, linker, etc.) are invoked during a build. This causes a lot of friction for package authors who want to do some basic customizations in order to build their targets. They often have to resort to awkward workarounds like creating custom modulemaps for linking system libraries, symlinking private headers inside the include directory, changing the include statements, and so on.

We think most of these workarounds can be removed by providing support for some common build settings at the target level. This proposal will also set the stage for a richer build settings API in the future that has support for various conditional expressions, deployment options, inheritance of build settings, etc.

Swift Forums

Mark Lacey wrote a proposal pitch to extend operator declarations with designated types, which could address the infamous “expression too complex” problems with operators in Swift.

Swift’s expression type checker is known to have cases where it is extremely slow in type checking expressions.

Some of these slow typechecking cases involve expressions that make use of operators (whereas others involve collections or chained single-expression closures).

This proposal addresses speeding up type checking for cases that are slow primarily due to the number of combinations of overloads of operators that are examined in the course of typechecking.

Joe Groff wrote a proposal pitch to lift the “Self or associated type” constraint on existentials.

When the first seed of Swift came out many years ago, there were technical reasons for the “self or associated type” constraint on protocol existentials: at that time, protocol witness tables did not carry associated type information, so it was impossible to re-open the dynamic type in order to dispatch methods on an existential when a protocol had associated types. This was fixed a while ago in order to allow for recursive protocol constraints, but we held on to the restriction on existentials thinking it would help avoid confusion or design dead ends with people using protocols as existentials in ways that we couldn’t really fully support yet.

However, nowadays we also have protocol extensions, so even if a protocol doesn’t have any core requirements with contravariant Self or associated type arguments, contravariant protocol methods can be added by extensions, so the type system issues unavoidably exist already.

Robert Widmann wrote a post outlining how you can contribute to the Swift compiler.

C++ is a notoriously dense language that can be a real pain to get a hold on. That said, LLVM-style projects have carved out their own subset of the language, and are very consistent about sticking to that subset. If you want to get a feel for the minutiae, the LLVM Coding Standards document is a great way to get a feel for the aesthetics. If you’re looking for a technical start, including programming patterns, data structures, algorithms, and more, look to the LLVM Programmer’s Manual.

I learn best by doing, so I’m sparse on book recommendations and such, but I think if you spend enough time with it that you can get up and working with LLVM-style structures pretty quickly.

John McCall shared an update on the Result proposal.

Based on the first round of feedback, the core team agrees that this feature is worth adding to Swift, and we are now looking for feedback on our proposed revisions to the proposal, which are at times substantial.

Thank you for everyone who participated in the first phase of review. Feedback there was generally positive on the idea of standardizing the widely used and reimplemented type.

The complete post goes into more detail and is worth a read.

Finally

Sometimes, Swift is really hard.