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!
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:
- SE-0351: Regex builder DSL (Rationale 🔄)
- SE-0352: Implicitly Opened Existentials (Review 🧵)
- SE-0353: Constrained Existential Types (Review 🧵)
On to new proposals in review!
SE-0354: Regex Literals
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
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:
/ 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
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
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
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 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 … 🌅
SE-0357: Regex-powered string processing algorithms
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:
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
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 🧵
swift testacross platforms: Discussion 🧵
String.Index’s printed descriptions: Discussion 🧵
- Have all adapters in the std lib expose their
base: Discussion 🧵
Other Developments worth Mentioning
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.
That’s it from my monthly update!