Overall being a big fan and fluent user of RegExes, I really like the pitch and the fact that we're planning on introducing RegEx literals in Swift.
My main concern, like many others above, is with all the impacts on using /.
At first I was like "yeah / makes ses because of term of art"… but now that I've realised how ambiguous it could be in all these situations (including with people already using libraries like PointFree's CasePath), I'm now +💯 on @ksluder 's suggestion of using #regex(…), which also matches precedents in Swift like #color(…) and #image(…) for other literals, and thus seems to fit very well here all while avoid the issues with /.
As for / being a term-of-art kind of separator, I'm not so sure that's strongly true. I mean yes many other languages use it for RegExes, but:
- Languages like Ruby also allow things like
%r{…}as an alternative for/…/orRegExp(…) - If you're copy/pasting your RegEx from another language or from StackOverflow, it is really not a big deal to replace
/…/with#regex(…): what matters is not the delimiters but what's inside them.
Overall, the argument that "this is what other languages use as delimiter and it will make it easy to copy/paste from SO" is not critical imho. Making it easy to copy/paste a PCRE-compliant RegEx content from SO or another language? Definitively yes, 100%. Considering that it's as important to be able to also copy the delimiters around that RegEx content from the SO answer without having to replace the surrounding / with #regex() when pasting into Swift? Not so much.
The important thing imho to be able to copy/paste from another source is the RegEx itself, not its delimiters.
So, TL;DR: Since #regex(…) seems to match with other precedent for specific literals in Swift, and avoids all the issues that / delimiters would raise, I think it's an excellent candidate.