SE-0354: Regex Literals

1-877-547-7272 · May 5, 2022, 8:28pm

Two ideas I haven't seen mentioned yet in this thread:

I think hiding the functionality of -enable-bare-regex-syntax behind a compiler flag is suboptimal. Xcode's build settings UI is hard to navigate and cluttered. And compiler flags aren't supported at all by playgrounds and Swift Playgrounds app projects.

What if, in addition to the flag, we added a new compiler control statement that enabled bare regex syntax?

#enable(bareRegexSyntax)

This would make bare regex syntax available in Swift 5 mode from day one, without the need to pass any obscure flags. It could also be extended to most other source-breaking changes, which parallels Doug Gregor's idea to create a compiler flag for each Swift 6 source break.

[Pitch #2] Regex Literals

[Pitch #2] Regex Literals
foo(op: /¢*¢/)
Unfortunately this would indeed become a regex literal. This is a variant of the unapplied infix / operator case, I will update the pitch to cover it. However unlike infix / , this cannot be disambiguated with parens, I think the best way of disambiguating would likely to be writing it as a closure, e.g:
foo(op: { $0 /¢*¢/ $1 })

I'm a bit uncomfortable with the fact that parentheses can't be used to disambiguate this case. Should we deprecate operators like this as well? Operators with more than one / can't be very popular, right? And if we implement ` delimiters for operators as suggested by tem, I think this will be even less of an issue.