Nothing about having it be a library means there's anything less in terms of usability, consistency, or tool support. It's not like people avoid System.Text.RegularExpressions because it doesn't have a compiler-intrinsic ~= match operator.
The exception I see is if a certain pattern requires a drastically different compilation method, even if only as an implementation detail. That would perhaps break debugging support. But that's not much of an argument, because nothing stops you from special-casing your tooling support (which you'd presumably do anyways).
It just seems incredibly inelegant to have to special-case things in a language when the general case could be implemented.
case /\(.+)!(.+)@(.+)/
nick, user, host = $1, $2, $3
...
vs
if( (match=new Regex("(.+)!(.+)@(.+)").Match(caseInput)).Success )
{
var nick = match.Groups[1].Value;
var user = match.Groups[2].Value;
var host = match.Groups[3].Value;
...
}
If I'm using a ton of regexps, having domain specific language support can certainly help keep things simpler and clearer, aiding usability by aiding readability. This is important enough people can and will resort to implementing their own domain specific languages. While I'm all for erring on the side of general purpose language features for a general purpose language, if only to reduce the possible explosion of corner cases for language design mistakes, discounting language level support as "inelegant" and having no benefits is, to me, tantamount to discounting DSLs in general for the same.
And perhaps you do so, but the argument doesn't resonate with me.
F# active patterns allow you to do exactly this kind of thing, in a general and extensive way, without building support for regex into the compiler. That's what I'm talking about.
And it takes all of 4 lines to add the support:
let (|Regex|_|) pattern input =
let m = Regex.Match(input, pattern)
if m.Success then Some(List.tail [ for g in m.Groups -> g.Value ])
else None
Boom, done. I'd call that a far more elegant approach than hardcoding regex into the language. Edit: And nothing is stopping the core developers from including such patterns in the standard library. So you get the best of both worlds, a common well-known manner, and a useful general purpose feature that people can extend and use if they need so.
Usage looks like:
match phone with
| Regex @"\(([0-9]{3})\)[-. ]?([0-9]{3})[-. ]?([0-9]{4})" [ area; prefix; suffix ] -> ...
The exception I see is if a certain pattern requires a drastically different compilation method, even if only as an implementation detail. That would perhaps break debugging support. But that's not much of an argument, because nothing stops you from special-casing your tooling support (which you'd presumably do anyways).
It just seems incredibly inelegant to have to special-case things in a language when the general case could be implemented.