I like backticks as a delimiter because it's already widely used when embedding code in Markdown, and regexes are more program than data. Backticks are also not as noisy as pound signs.
But there is a slight issue that would make it ambiguous if backticks could also surround operators in the future:
`/.*/` // operator or regex literal?
By the way, a potential issue with backticks surrounding operators is that they could be juxtaposed with backticked identifiers:
which at the very least doesn't look clear. But it would be extremely rare.
Backticks could also extend neatly to generalized foreign language multi-line literals by mirroring Markdown:
But I'm not sure what the compact one-line version would look like, whereas
#sql'SELECT * FROM users;' would work well I think (using backticks even, but I can't figure out how to put backticks inside backticks here).
Right now I'm more in favor of the "allow only extended regex literals" alternative with the proposed
#/../# syntax, even though I still think that anything but a clear and firm promise to never introduce
/../ may have a self-reinforcing effect if CasePaths gets assimilated into the language, because library authors would avoid creating new operators that are in jeopardy of future source break, wouldn't they? I think
#/../# could be quite noisy in some situations but the best way to find out is to let people use it for some time.
Either that or completely rejecting regex literals (for now) to give us some more time to evaluate the alternatives. All of the other new regex-related features will be plenty to get excited about when they drop!
Actually, (I've had another change of heart) if the popular CasePaths library is given enough time to migrate the source breakage (via the
-enable-bare-slash-regex compiler flag) then I guess accepting
/../ would be the pragmatic choice, if not the ideal one. Aside from the concrete source break, cutting into the very limited pool of viable custom operator symbols hurts a bit, but custom operators are admittedly an already somewhat esoteric feature and if the actual demand for
/-containing (prefix) operators is very low (which it seems to be, outside of CasePaths), then it seems like a reasonable compromise.
Additionally, generalized foreign language literals are not precluded by this choice. Deciding on regex literals before a more general design might well make regex literals inconsistent with those future foreign language literals, but that's not a big issue. I don't even know of any languages with such a generalized feature (Markdown code blocks don't count), whereas regex literals do exist in other languages, so it's ok for regex literals to be treated specially in Swift too IMO (even if regexes are often obtuse and 'arcane' or 'legacy').
I'm very interested in a comprehensive, more modern, replacement for regexes as @Nevin has advocated, but I'm not aware of any existing prototypes/designs that we could evaluate today. It seems like something that could take years and I don't see the benefit of holding back on first-class regex support that has already been (mostly?) implemented. If there is some all-new design that's clearly better than regexes, then I don't see why that would be precluded by regexes existing in the language. There were vague claims to that effect, but one could also counter, vaguely, that having first-class regex support sets the bar for any alternative to have to clear, and would make it easier to compare and contrast the two.