From the radar issue submission: > Any modern language should natively support regular expression literals Regex literals add needless complexity to the language, and tie it with a specific regex implementation, with no real benefit. Just because Perl/JS/Ruby have this kludge, doesn't mean a modern language "should" have it. Now, a way to write unescaped strings (e.g not having to escape all the regex operators like…
There are real benefits, they're called convenience and compatibility. And what's wrong with tying a language to a specific regex syntax? After all, you're also tying it top a specific outside-of-regexes syntax. Regexes are also code, they just happens to be written in a different sub-language than the rest of the program.
Besides the fact that built-in regex literals are hardly any more "convenient" than a function call (a few keystrokes saved at best), regexes shouldn't be "convenient".
If anything, they should be discouraged. To quote JWZ: "Some people, when confronted with a problem, think 'I know, I'll use regular expressions'. Now they have two problems."
Oh, and "compatibility" doesn't come to play at all. Why would regex literals be any more "compatible" (with what?) than a regex object/functions? Compatible to what? JS and Ruby syntax?
>And what's wrong with tying a language to a specific regex syntax? After all, you're also tying it top a specific outside-of-regexes syntax.
For one, because you have to keep maintaining it forever, as part of the core syntax, whereas with a library you could deprecate it. It's not like there aren't several regex flavors, and approaches on how execute them (e.g: http://swtch.com/~rsc/regexp/regexp1.html ).