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:
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:
We will also get a new [ranges](https://github.com/apple/swift-evolution/blob/main/proposals/0357-regex-string-processing-algorithms.md#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:)](https://developer.apple.com/documentation/foundation/nsstring/1412937-replacingoccurrences) which will now get a new [replacing(_:with:)](https://github.com/apple/swift-evolution/blob/main/proposals/0357-regex-string-processing-algorithms.md#replace) 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](https://github.com/apple/swift-evolution/blob/main/proposals/0357-regex-string-processing-algorithms.md#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.