Swift Evolution Monthly: April ‘22

Wow, this is just the 2nd issue of this newsletter and nearly 300 developers subscribed to it, already! All thanks to Dave and others from the community for spreading the word. Thank you! 🙏

I heard your feedback: You’re right, the first issue was too long. Partly because it was never planned to be released as a newsletter, and partly because it was the first, so I gave a (lengthy) introduction. Despite covering more proposals today, this issue is only ~60% of the length! (2,400 words → 1,500 words)

The two main focus topics on Swift Evolution this past month both sound a bit scary: Regular Expressions and Existentials. But don’t worry: The Regex story can be broken down to “Swift is making them less scary!”. And I didn’t know what an “Existential” was before writing this issue myself — I’ll explain!

Enjoy. 🍻

Accepted Proposals

The following proposals presented in past issues have been accepted:

• SE-0344: Distributed Actor Runtime (Rationale ✅)
• SE-0345: if let shorthand for shadowing an existing optional variable(Rationale ✅)
• SE-0346: Lightweight same-type requirements for primary associated types(Rationale ✅)

Also, one more proposal was accepted that I had not mentioned because I found it not relevant to app developers. From now on I’ll mention these kinds of proposals, too, with a short comment on who this might be of interest to. This one mostly concerns those shipping Swift packages to Linux systems:

• SE-0342: Statically link Swift runtime libraries by default on supported platforms (Rationale ✅)

On to new proposals!

SE-0347: Type inference from default expressions

Links: Proposal Document 📝 | Acceptance Rationale ✅ | Review 🧵

Currently, providing a default value for generic parameters produces an error:

Starting with (probably) Swift 5.7, the above code will compile successfully! Here’s another example of what will be possible with the usage side included:

SE-0348: buildPartialBlock for result builders

Links: Proposal Document 📝 | Review 🧵

This one will only concern you directly if you try writing a DSL using Result Builders. But even as a user of frameworks like SwiftUI or Point-Free’s swift-parsing, you are going to benefit from this indirectly because it significantly reduces the number of overloads the library authors have to write to make things like VStack support multiple subviews.

This should allow Apple to accept more than 10 views in the future, making workarounds like Group less necessary. Point-Free has already reported that they will be able to increase their parser builder limit from 6 to above 10 and even to infinity for some specific combination of types. Cross-platform SwiftUI implementations such as Tokamak or Swift Cross UI should profit from this, too. It’s also going to allow for new types of builders, such as the new RegexComponentBuilder planned for the Regex proposals below.

The feature is already implemented and will ship with Swift 5.7.

SE-0349: Unaligned Loads and Stores from Raw Memory

Links: Proposal Document 📝 | Acceptance Rationale ✅ | Review 🧵

Helps prevent alignment mismatches in low-level byte data parsing by introducing a new loadUnaligned function. Probably ships with Swift 5.7.

Proposals In Review/Revision

For the following proposals, you can still provide feedback. The current rejection rate is less than 10%, so it’s likely they get accepted. Revisions are more common.

SE-0350: Regex Type and Overview

Links: Proposal Document 📝 | Review 🧵

This is a big one. Not necessarily this proposal specifically. But it is kicking off a series of Regex-related proposals that are going to greatly improve how we can process Strings to read/transform specific data from parts of them. To put things in context, this is the start to implement Declarative String Processing in Swift, which itself is part of a larger data processing improvement plan.

But let’s get back to this proposal in particular. It introduces a Regex type:

As you can see, unlike NSRegularExpression, the new Regex type will be generic over its output, allowing for more type safety when dealing with Regexes. The Regex type will ship with a whole set of functions, such as firstMatch(in:)returning a Regex<Output>.Match?, which is a wrapper for the matched range and the typed output.

SE-0351: Regex builder DSL

Links: Proposal Document 📝 | Review 🧵

This adds a SwiftUI-like DSL for constructing a Regex. The email Regex with two capture groups from above would look something like this:

Furthermore, a ChoiceOf builder would allow specifying multiple variants (replaces A|B) and even a TryCapture {} transform: {} would be available to directly transform a sub-match into an expected type, such as into an enum. Optionally (for A?) and Repeat (for A{n,m}) complete the DSL:

This builder DSL doesn’t only make Regexes much more readable and easier to reason about, it also allows for extracting portions of the code out into their own smaller Regexes, much like we can extract out parts of the body in SwiftUI views. The new DSL should remove the hurdle for those who were put off by Regexes due to the cryptic syntax. And I can easily imagine the community creating libraries of common reusable Regexes, such as for matching email addresses.

SE-0352: Implicitly Opened Existentials

Links: Proposal Document 📝 | Review 🧵

Before we get to the proposal, let’s first clarify the term “Existential Type”: Whenever you define a variable or a parameter of a protocol type, you’re creating an existential type. It’s just a shorter way of saying “any type that conforms to a given protocol, but it’s not (yet) clear which type exactly”. From the compiler’s perspective, it has to create something like a “box type” until the exact type of your variable becomes clear, this type is called “existential”.

For example, this code works in Swift 5 by creating an existential type:

The value variable is of type “any type that conforms to Codable". First, we use a [String], then a plain String and it compiles successfully. Under the hoods, Swift 5 creates an existential box type for us implicitly and dynamically changes the type of the value stored inside it from [String] to String.

Since Swift 5.6 (thanks to SE-0335) we can (and should!) make this existential more explicit by adding the keyword any in front of Codable:

Starting with Swift 6, the first example will no longer compile and we will need to add any whenever we’re creating an existential type, to make its creation more explicit to developers. This is important because existential types are quite limited in Swift. Some of these limitations come from their type-erasing nature and can’t be fixed, but some can be fixed.

Developers would run into a whole set of compilation errors and had to work around them. But we are going to see improvements in the near future, like with SE-309 shipping with Swift 5.7.

This proposal further improves working with existentials by smoothing out the interaction between them and generics. Calls to generic functions that would have failed with an error like “protocol ‘P’ as a type cannot conform to itself”, will now succeed. Additionally, before this, we could replace a some View parameter with any View, but not the other way around. This proposal would allow us to refactor in the other direction as well.

SE-0353: Constrained Existential Types

Links: Proposal Document 📝 | Review 🧵

In the previous issue, we discussed SE-0346 which allows us to specify generic types in place instead of specifying them with a where clause at the end. This proposal aims to bring the same convenience to existential types with the anykeyword:

Recently Active Pitches/Discussions

Here are some pitches/discussions with a recent activity you might find interesting — some of them are a continuation of topics discussed above. Of course, I will cover them in more detail once they become official proposals:

• Regex Literals: Discussion 🧵
• Regex-powered string processing algorithms: Discussion 🧵
• Regex Syntax and Run-time Construction: Draft 📝 | Discussion 🧵
• Precise error typing in Swift: Discussion 🧵
• SwiftPM support for Swift scripts (revision): Discussion 🧵
• Swift Snippets: Draft 📝 | Discussion 🧵
• Inclusion of CasePaths into the language: Discussion 🧵
• Global actors: Draft 📝 | Discussion 🧵
• for-where-as: Discussion 🧵
• Primary Associated Types in the Standard Lib: Draft 📝 | Discussion 🧵
• Full name identifiers: Discussion 🧵
• Build-Time Constant Values: Discussion 🧵

Other Developments worth Mentioning

Apple officially announced the release process for Swift 5.7 on March 29th. Doing the math based on this table in the Swift GitHub repo, a Swift release happens 5–6 months after its announcement on average. So it’s pretty safe to say we’ll be getting Swift 5.7 as part of the Xcode 14 release this autumn, starting with a first beta right after the WWDC22 keynote on June 6th.

In another announcement from March 22nd, Apple laid out a timeline for migrating Swift bug reports over to GitHub from a separate JIRA system that was in use until now. This should help with linking bugs to PRs properly as both the code and the related issues can live in one place. Also reporting bugs should become easier as you can just use your existing GitHub account. At the moment of this writing, the migration is ongoing and we can see a read-only preview of the migrated issues. The migration is planned to be completed by April 28th, then you should see the Issues tab in the Swift repo.

That’s it from this month’s update!