Make regexes almost first-class Rust syntax (like Perl)

[daniel-pfeiffer]

Regex::new(r"…").unwrap() looks rather heavy and unelegant (coming from Perl where I could just /…/.) To make it a bit leaner, I propose implicitly raw-string procedural macro equivalent of:

macro_rules! re {
    ($re:expr) => { regex::Regex::new($re).unwrap() };
}
macro_rules! re_set {
    ($($re:expr),+) => { regex::RegexSet::new(&[$($re),+]).unwrap() };
}

These could then be used as re!(a[)}](.?)\(a). For sets this is not directly possible, because the separator is indistinguishable from regex comma. As a compromise, it could require literal commas to need masking. E.g. a set of 2: re_set![a.?[,]a, o.?\,o].

Since the macro delimiters, when used in the regex, must be balanced or masked as in re!(…[)]…\(…) above, I don't see a possible conflict.

[BurntSushi]

I'm going to have to decline for a few reasons:

1. I find little elegance in Perl. This is obviously quite subjective, but we clearly have opposing views on this.
2. A short macro like re! encourages users to repeatedly compile regexes in a loop. Perl doesn't suffer from this problem because it does caching (AIUI). This crate does not do caching. This could be mitigated by using the recently stablized std::sync::OnceLock.
3. Rust has excellent support for raw string literals. I see no compelling reason to write yet another regex parser (which is likely required given your requirements) just to avoid typing r"...". (Or r#"..."# in the case of your regex containing a double quote.)
4. This feature would require maintaining an extra procedural macro crate. And this in turn would likely require bringing in some heavy dependencies (like syn). This seems like the wrong trade-off to me. "Use this really succinct way of creating regexes. It looks really elegant! You just need to be cool with adding N seconds of compile-time to your project."

I think that #709 is a far more likely path. By requiring users to use raw strings, it vastly simplifies its implementation. The other advantage is that it works today. You can define that macro yourself in your crate in a couple lines.

[daniel-pfeiffer]

Hi Andrew,
thanks for the swift response!

1. Since I know Rust, I find Perl less hot, except regexes. They are such a brilliant language that they deserve a 1st row seat! Like serde_json or yew which pull languages into Rust.
2. There could be variants like once_re and sync_re in line with provide a helper routine for building a static regex using std::lazy #709, and a clippy cough for re in a loop…
3. Powerful, and clutter…
4. You're the expert on this. I learned with a twang of pain, we may not be getting const regexes. Maybe just the parser could be, generating some const data structure from which the automaton would be assembled at run time? If all come from literal strings (and splitting new), the bin would be smaller, as the parser wouldn't be linked in. The benefit also being that we could get error messages from the compiler. I know clippy parses them, but at least I run that much rarer.

[BurntSushi]

1. I don't necessarily agree they deserve a front row seat. I tried to say already that we have a fundamental disagreement here.
2. Oh my heavens no. Talk about clutter... And it makes the shorter and more succinct version an instant footgun.
3. Not enough clutter to justify your request.
4. Please see the other discussions on const regex. A const parser is perhaps a little simpler, but not much more. It still uses a significant chunk of the Rust language. Including heap allocation. So this isn't happening either unless there are significant developments in what can be const.