{"id":33800,"date":"2021-10-01T17:00:51","date_gmt":"2021-10-01T21:00:51","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=33800"},"modified":"2021-10-15T15:56:26","modified_gmt":"2021-10-15T19:56:26","slug":"swift-declarative-string-processing-pitch","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/10\/01\/swift-declarative-string-processing-pitch\/","title":{"rendered":"Swift Declarative String Processing Pitch"},"content":{"rendered":"

Michael Ilseman<\/a> (tweet<\/a>):<\/p>\n

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

[…]<\/p>

We propose adding a new regular expression literal, with strongly typed captures, to Swift.<\/p>

[…]<\/p>

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

[…]<\/p>

We intended to extend and add generic consumer and searcher<\/a> algorithms to the standard library for operating over collections using patterns or regexes.<\/p>

[…]<\/p>

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

Michael Ilseman<\/a>:<\/p>\n

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.<\/p>

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.<\/p>

[…]<\/p>

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.<\/p><\/blockquote>\n\n

Previously:<\/p>\n