Hello all! I truly hope you enjoyed Thanksgiving and were able to spend the holiday with your loved ones. Maybe some of you even played Chandler’s invented game of naming all 50 states in 6 minutes.

The period after Thanksgiving was very productive for the Swift team, and there’s a lot of activity to discuss today. But before we jump into it, I’d like to use this opportunity to say that the next issue will be the last issue for me and maybe for this project. Please let me know if anyone is interested in taking over my duties. I would love to see this project stay alive and thrive after I leave.

News and community

Keith Smiley shared updates about Swift 5.5 and it’s cherry-picking triage process.

John Sundell wrote an article exploring how to use count vs. isEmpty to check whether a collection contains any elements.

Will Lisac tweeted that Swift 5.5 Docker images for Raspberry Pi are now available.

A great illustration by Feli. Worth to check out her sketches from various conferences.

Max Desiatov announced that the SwiftWasm 5.5.0 is now available.

Accepted proposals

SE-0328 Structural opaque result type was accepted with modifications.

During the review, there were two main areas of discussion:

• The spelling of optional types. The proposal leaves this as (some P)? even though some P? is more succinct and could potentially be allowed as sugar. The core team agrees with this more conservative approach, which could be revisited later after more experience with the feature.
• The use of some in “consuming” rather than “producing” position when returning function types i.e. f() -> (some P) -> Void. Discussion of other uses of the some keyword is ongoing, and there was concern about potential conflict with those future uses. Since the use of opaque result types in consuming position is not especially useful (such functions are uncallable in all but a few circumstances) the core team has decided to subset out this use, requiring opaque result types only in the return value of returned function types for now.

Proposals in review

SE-0332: Package Manager Command Plugins is under review.

SE-0303 introduced the ability to define build tool plugins in SwiftPM, allowing custom tools to be automatically invoked during a build. This proposal extends that plugin support to allow the definition of custom command plugins — plugins that users can invoke directly from the SwiftPM CLI, or from an IDE that supports Swift Packages, in order to perform custom actions on their packages.

SE-0331: Remove Sendable conformance from unsafe pointer types is under review.

SE-0302 introduced the Sendable protocol, including Sendable requirements for various language constructs, conformances of various standard library types to Sendable, and inference rules for non-public types to implicitly conform to Sendable.

Experience with Sendable shows that this formulation is unnecessarily dangerous and has unexpected negative consequences for implicit conformance.

SE-0333: Expand usability of withMemoryRebound is under review.

The function withMemoryRebound(to:capacity:_ body:) executes a closure while temporarily binding a range of memory to a different type than the callee is bound to. We propose to lift some notable limitations of withMemoryRebound and enable rebinding to a larger set of types, as well as rebinding from raw memory pointers and buffers.

Note this proposal is running concurrently with SE-0334 which also relates to unsafe pointer usability.

SE-0334: Pointer Usability Improvements is under review.

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. Add the ability to compare pointers of any two types.

Note this proposal is running concurrently with SE-0333 which also relates to unsafe pointer usability.

Swift Forums

Ethan Kusters started a discussion about support hosting DocC archives in static hosting environments.

This post discusses an enhancement to Swift-DocC and Swift-DocC-Render that will allow developers to build DocC archives that can be hosted without custom routing. This is specifically designed to enable DocC to be used in additional static hosting environments, most notably GitHub Pages.

This change is meant as a quick solution to address a pressing need, and provides general goodness. But please know that we’ve heard the community’s feedback that they would love for Swift-DocC to directly emit static HTML, and this feature is high on the priority list.

Sam Deane pitched an idea to implement a default initable protocol.

I’ve come across factory-type situations where I’ve ended up making a protocol to represent that “this type can be constructed with a default init that takes no arguments”.

I’ve found myself wondering (a) whether this protocol already exists somewhere in the standard library, and (b) whether Swift could auto-conform any type to it if an init() exists for it.

A good reminder that a library Swift Numerics does exist.

Guillaume Lessard pitched a proposal to make slices of buffers more useful, especially with respect to partial initialization of buffers.

Sub-sequences of the UnsafeBufferPointer family have all the [Mutable]Collection API of UnsafeBufferPointer, but have none of their buffer-specific API. This makes partial initialization of a buffer difficult, among other tasks.

Finally

iPhone Development Tutorial - 1 - Installing Xcode and the iPhone SDK..

The History of the Web.