Friday, October 1, 2021

Swift Declarative String Processing Pitch

Michael Ilseman (tweet):

String processing is hard and the current affordances provided by the Swift Standard Library are underpowered. We propose adding two new declarative string processing APIs—a familiar Regex literal and a more powerful Pattern result builder—to help make Swift string processing fast and easy.


We propose adding a new regular expression literal, with strongly typed captures, to Swift.


Sophisticated features like inline capture group processing feel right at home with the result builder syntax because it’s all just regular Swift code—it isn’t nearly as natural to try to force this kind of functionality into the regex literal.


We intended to extend and add generic consumer and searcher algorithms to the standard library for operating over collections using patterns or regexes.


The Swift operator ~= allows libraries to extend syntactic pattern matching by returning whether matching succeeded or not. An enhancement to this would allow libraries to produce a result as part of a destructuring pattern match, allowing patterns and regexes to be used inside case syntax and directly bind their captures to variables.

Michael Ilseman:

I’ve been finding it helpful to think of our long-term goal as making Swift awesome at string processing, data processing, and “event processing” (working title, suggestions welcome). These are not rigid or clear-cut distinct domains (they actually blend together in extremity) so much as they are 3 interesting “regions” in this design space. Thinking about these regions helps clarify what tasks we’re enabling and helps push us towards more general solutions.

Each of these regions share technical fundamentals, but present novel performance and API design challenges. I hope that keeping the big picture in mind will help guide the design process towards pragmatic trade-offs and robust solutions.


We want to be able to compose, layer, and even interweave different kinds of processing together. And, we want these areas to be library-extensible, so that libraries can provide custom behavior through custom protocol conformances.


Update (2021-10-15): Hamish Knight:

We propose to introduce a first-class regular expression literal into the language that can take advantage of library support to offer extensible, powerful, and familiar textual pattern matching.

Comments RSS · Twitter

Leave a Comment