I am strongly opposed.
Regular expression literals, in the standard forms that exist today, are antithetical to Swift’s goal of clarity at the point of use. They form a dense jumble of arcane symbols all mashed together.
Introducing regex literals into Swift would be actively harmful to the language, by encouraging programmers to write code that hinders readability, whose meaning is non-obvious, and which cannot be understood at a glance.
Rather than “ubiquitous, familiar, and concise”, as the pitch claims, I see regex literals instead as being obscure, esoteric, and inscrutable. They are the specialized jargon of a particular problem domain, concocted out of a desire to prioritize character counts over comprehensibility.
While that goal may perhaps have served a purpose at the time they were invented last century, it is no longer a useful aim and we should not reshape a modern language to accommodate a feature so thoroughly incompatible with present-day design standards.
• • •
We should instead focus on designing a rich, powerful, first-class pattern-matching and string parsing system for Swift, built to prioritize self-documenting readability, that looks and feels like ordinary Swift code at the point of use.
Then, after we have built the infrastructure and created a proper solution which enables programmers to parse and match strings in native Swift, if there is still a reason to consider introducing regex literals, we may revisit the question.
But until then—until we have seen what we can do without sacrificing readability—I see no reason to compromise the principles of the language. The costs to code comprehension are high, and the benefits are not commensurate.