Swift Evolution Monthly: May ’22

Regex overhaul (pt. II), Swift Snippets, new Workgroups

Swift Evolution Monthly: May ’22
Photo by Annie Spratt / Unsplash

Last month I presented the first two Regex (or String-processing) related proposals, stating that they are just “kicking off a series of Regex-related proposals”. And here we are, Regexes still being the main focus — and they will probably still be in next month’s issue.

But that doesn’t mean nothing else happened on Swift Evolution. There’s a very interesting proposal for adding Snippets support to SwiftPM. Also, multiple entirely new pitches were made by the community, some of which I’m linking below. And there’s also news on the organizational front.

Read on to learn more about all these developments!

Accepted Proposals

The following proposal already presented in the past has been accepted:

No other proposals were accepted within the last month!

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.

The following proposals already presented were returned for revision:

On to new proposals in review!

SE-0354: Regex Literals

Links: Proposal Document 📝 | Review 🧵

Regex literals will provide a safer way to define regular expressions than passing a pattern String: While a pattern String can only be checked for syntax errors (such as an opening brace ( without a closing brace )) during runtime (= when the code is executed by the user), the literal can be checked at compile-time (= when you build your app) and therefore it will help reduce crashes for your users or error handling code for you because you don’t have to catch any errors. The syntax will look familiar to those experienced in languages like Ruby, Perl, or JavaScript:

Comparison of different ways to initialize a regular expression in Swift soon.

Note that in the /../ literal form, there’s no need to escape characters like \ to make them work as Regex meta characters. The only character that will require escaping is the / itself. To work around this, you’ll be able to surround your pattern #/.../# much like you can do today with Strings when you want to use the character " inside a String (e.g. #"Press "Done"."#). So for a regex matching the WWDC website, you might write something like:let httpUrlRegex = #/http://developer\.apple\.com/wwdc22/#

I like that the proposal also covers typed captures and named captures — a nice resource to learn about them with example Swift code that’ll work in the near future. Additionally, some extra love was given to more complex multi-line literals. They will support comments via # and ignore whitespaces for alignment of parts of regexes for better readability, see this example:

The (?<name> pattern) is a “named capture” that can be referenced by `.name` rather than`.0`.

Because / is used in other places in Swift today, the introduction of Regex literals is a source-breaking change and will be disabled by default until Swift 6 is released. You’ll be able to activate them in your project by passing -enable-bare-regex-syntax in Swift 5.x mode, or just use #/.../#.

SE-0355: Regex Syntax and Run-time Construction

Links: Proposal Document 📝 | Review 🧵

This proposal goes into all the details of how the String pattern in the throwing Regex.init(String) initializer already shown above (where only runtime checks are possible) will be processed. I think it’s a great reference for everybody running into problems with more complex Regexes long term.

For everyone else, the main takeaway is that the Swift engine will be superior to any other Regex engine because it will support a wide range of existing engines/standards and character classes. So it’ll be highly likely that copy & pasted patterns written for other platforms will work in Swift!

SE-0356: Swift Snippets

Links: Proposal Document 📝 | Review 🧵

This proposal at first might sound like the Xcode snippets feature, I personally even thought (or hoped?) it was related to Swift scripts in some way. But none of that is true. This proposal is mostly aimed at library authors and provides them with another way to document functionality. This sentence in the proposal summarizes the direction of the feature pretty well, I think:

Making it easy to add code listings to documentation that can also be built and run (and validated) is one of the main goals of snippets.

While sample projects are great to show off how everything fits together, they are hard to maintain and don’t help with exploration to potential users. Extensive code examples right within documentation comments are much more explorable because you can easily show them via alt-clicking APIs right within Xcode when you need them. But from the compiler’s view, they are just plain Strings, and thus when you make changes to your APIs, it’s easy to forget to update the related code examples accordingly and they get outdated.

Snippets fix the latter. You provide them as separate files in a Snippets folder within your Swift package & you can also group them, like so:

Then, in your documentation comments, instead of placing sample code via three backticks, you’ll be able to just use the new DocC directive @Snippet:

This will place the presentation code of your snippet file right into the documentation view within Xcode or add it to your HTML file. What is the presentation code, you ask? Well, because all snippet files will be Swift files that we will be able to compile via swift build --build-snippets (and library authors should make sure to run that on their CI), you might need to write some helper code that is just churn and might not be relevant to showing off your functionality. The proposal gives us a way to hide some parts of our code, for that we simply add // MARK: HIDE and // MARK: SHOW:

The highlighted code is the “presentation code” in this example. Note also the description at the top.

The cool thing is that all snippet files will get full access to all targets of your package, you just need to import them. External dependencies can’t be imported as part of this proposal, but they are mentioned in future directions.

Lastly, the proposal also mentions that snippets could be provided as standalone repositories, without any (real) package attached:

Examples of snippet-only packages might be a collection of recipes for composing UI elements in new and interesting ways, teaching the Swift language snippet by snippet, or providing exercises for a textbook.

I can already see some great community projects on the horizon here … 🌅


Want to see your ad here? Contact me at ads@fline.dev to get in touch.

SE-0357: Regex-powered string processing algorithms

Links: Proposal Document 📝 | Review 🧵

This one adds a whole bunch of new APIs that will simplify a lot of String processing code but not only that, collection types will profit from these APIs as well! And many of the new APIs are not even Regex-related, so I find the title a bit misleading. For example, there will be a new contains function which you can pass a sequence — currently, we can only pass a single element:

We will also get a new ranges function saving us from writing a loop or reduce function just to get multiple matching ranges, see this example:

And there are still many APIs we only have access to through NSString (and therefore Objective-C), like replacingOccurrences(of:with:) which will now get a new replacing(_:with:) Swift-native API.

See this table for a summarizing list of all new APIs getting added to Swift.

On top of these new APIs, the proposal is also adding a ~= operator overload for pattern matching with Regexes + a new CustomConsumingRegexComponent protocolwhich will allow Apple & 3rd party library authors to make their own types directly usable in many of the new APIs + within the Regex builder DSL.

SE-0358: Primary Associated Types in the Standard Library

Links: Proposal Document 📝 | Review 🧵

This one is a follow-up proposal to SE-0346 (presented in first issue) and basically is about extending the Standard Library with the new primary associated type declarations in order to make SE-0346 actually usable.

See this table for an overview of all the protocols planned to be changed.

Recently Active Pitches/Discussions

Some threads inside the “Evolution” category with activity within the last month I didn’t link yet. I’ll cover them once they become official proposals:

  • Piecemeal adoption of Swift 6 features in Swift 5.x: Discussion 🧵
  • Keypath-based sort/min/max Sequence operations: Discussion 🧵
  • Allow non-optional getters for optional requirements: Discussion 🧵
  • Unicode for String Processing: Draft 📝 | Discussion 🧵
  • Will string processing efforts also expose Bidi_Class?: Discussion 🧵
  • Approximate equality for floating-point: Discussion 🧵
  • Opaque result types with limited availability: Discussion 🧵
  • Standardise swift test across platforms: Discussion 🧵
  • Improving String.Index’s printed descriptions: Discussion 🧵
  • Have all adapters in the std lib expose their base: Discussion 🧵

Other Developments worth Mentioning

The migration of Swift bug reports to GitHub has been completed with more than 12,000 issues of which more than 5,000 are marked as “Open”: See here.

Ted Kremenek, officially representing Apple in the Swift community and Core Team member, posted an update to the same thread where Chris Lattner, the originator of Swift, had posted his reasons to depart from the Swift community (which I had already discussed at the end of the first issue). This shows that their efforts to split the Core team’s responsibilities for improving upon some of the criticized aspects are making progress.

More specifically, he mentions a new language design work group and that “the goal is to make the core team more of a general oversight group”. He specifically mentioned that a documentation tooling workgroup is being discussed, an also mentioned Swift website workgroup was already formed with none other than Paul Hudson and Dave Verwer as members, among others.

On the same note, a Numerical/ML workgroup is being discussed, too. And speaking about workgroups, the Swift Server Workgroup has just posted its annual update.

That’s it from my monthly update!

💁🏻‍♂️
Enjoyed this article? Check out my app RemafoX!
A native Mac app that integrates with Xcode to help translate your app.
Get it now to save time during development & make localization easy.
👨🏻‍💻
Want to Connect?
Follow me on 👾 Twitch, 🎬 YouTube, 🐦 Twitter, and 🦣 Mastodon.