My last issue. I have had such a great time writing this newsletter with the help of some great friends, and I can’t thank all of you enough.

I’m very excited for the future of the newsletter now that Kristaps is taking it over, with me watching from the sidelines.

All the best,
Bas

Interested in sponsoring Swift Weekly Brief? Learn more here.

News and community

Michael Ilseman shared that Swift System, which provides idiomatic interfaces to system calls and low-level currency types, is now open source!

Karoy Lorentey introduced Swift Atomics, a new open source package that enables direct use of low-level atomic operations in Swift code.

Kishikawa Katsumi shared the Swift Abstract Syntax Tree (AST) explorer now runs on Swift 5.3.

Nate Cook announced Swift Algorithms, a new open-source package of sequence and collection algorithms, along with their related types.

Commits and pull requests

Doug Gregor merged a pull request adding support for function builders on stored struct properties.

Holly Borla merged a pull request adding support for local property wrappers.

Konrad Malawski merged a pull request, introducing metrics to the Scalable Weakly-consistent Infection-style Process Group Membership Protocol (SWIM) implementation.

Robert Widmann merged a pull request turning on Cross-Module Incremental builds.

Proposals in review

SE-0289: Result builders is under a second review.

There were a few concerns that were brought up, with one that clearly stood out: naming. Given this feedback, the core team decided to re-run the review to rename the attribute based on the suggestions that garnered traction during the review. Additional concerns that were brought up were around the documentation of the feature as well as concerns around tooling with things such as diagnostics. There has been work to address this feedback as well with improvements to the documentation in the proposal and additional diagnostics in the compiler.

There was some feedback over additional features such as enabling stateful builders and handling for the Never and Void types. These are interesting avenues to explore for future extension; however, the core team believes that they can be reasonably considered by later proposals.

This review is limited to:

• the name of the feature and its attribute and
• arguments that one or more of the suggested extensions will be problematic to explore in the future

Swift Forums

Ilias Karim pitched a proposal improving assigning of a case statement to a boolean.

Given that case can appear in an if statement without variable assignment, it has me scratch my head a bit why it can’t be used to assign a boolean value.

In other words, seeing as this code works,

enum Enum {
  case aCase
  case anotherCase
}

let value = Enum.aCase

if case .aCase = value {
  print("a case")
} else {
  print("another case")
}

then it follows that this should as well,

let bool = (case .acase = value)

Filip Sakel, Anthony Latsis and Suyash Srijan pitched a proposal to unlock existentials for all protocols.

Swift currently offers the ability for protocols that meet certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error [the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements. This proposal aims to relax this artificial constraint imposed on such protocols.

Justin Reusch shared some takeaways from the Rust ecosystem.

In short, this is a few take-aways from my experience with the Rust ecosystem that we could adopt to make Swift even better:

• A toolchain manager for Swift
• A package registry
• More “Swifty” testing
• Generated documentation
• An online playground
• Command-line benchmarking
• Make Swift more “self-contained” from Xcode
• Reduce the size of the Swift toolchain (if possible)

Note that this isn’t really a single proposal, but a number of discussion staters, each of which could be its own proposal.

Soroush Khanlou and Tim Vermeulen pitched a proposal for a sum function accepting a closure.

While Swift’s Sequence models brings a lot of niceties that we didn’t have access to in Objective-C, like map and filter, there are other useful operations on sequences that the standard library doesn’t support yet. One operation that is currently missing is summing numeric values on elements in a sequence.

Holly Borla and Filip Sakel pitched a proposal extend Property Wrappers to Function and Closure Parameters.

Property Wrappers were introduced in Swift 5.1, and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending where property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.

Maxim Ovtsin pitched a proposal allowing to opt-in to reflection metadata.

Reflection can be a useful thing to create convenient and concise APIs for libraries. This proposal seeks to improve the safety of such APIs and to tackle the binary size problem by introducing a mechanism to selectively enable reflection metadata only for types that need it and add a way to express a requirement of reflection metadata for APIs developers.

Jon Gilbert pitched a proposal to revisit and implement typeprivate.

The idea is to add typeprivate so you can put extensions into separate files to improve code readability without having to resort to internal. (Currently any extensions that access private stored properties must all be in the file that declares the type, and fileprivate must be used. However this can lead to bloated code files.)

If the original typeprivate is seen as too “loose,” here are two extra restrictions that would make typeprivate unable to be stealthily abused.

Finally

If the emotional support dog is around, you better not make any typos.