Does not support (?!...) negative lookahead assertion?

[messense]

Python re module supports (?!...) syntax, see https://docs.python.org/2/library/re.html#regular-expression-syntax

The code below compiles but paniced at runtime:

extern crate regex;

fn main() {
    let re = regex::Regex::new(r"Isaac (?!Asimov)").unwrap();
    println!("{}", re.is_match("Isaac "));
    println!("{}", re.is_match("Isaac Asimov"));
}

thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value:
Syntax(Error { pos: 8, surround: "ac (?!Asim", kind: UnrecognizedFlag('!') })', 
../src/libcore/result.rs:738

The pattern works fine in Python:

import re

pt = re.compile(r"Isaac (?!Asimov)")
pt.match("Isaac ")
pt.match("Isaac Asimov")

[BurntSushi]

Those aren't supported. From the documentation:

Notably, backreferences and arbitrary lookahead/lookbehind assertions are not provided. In return, regular expression searching provided by this package has excellent worst-case performance. The specific syntax supported is documented further down.

The reason why your code panicked is that the regular expression is invalid and your code called unwrap on it.

[messense]

So when I need to use those unsupported syntax, is there anything I can turn to?

[BurntSushi]

I don't know because I don't know what problem you're trying to solve. Any of the following things might work depending on your situation:

1. Reformulate your regex into one that does not require arbitrary look-ahead in the input.
2. Post process your matches to exclude matches that would have been excluded by the negative assertion.
3. Use rust-pcre (I'm not sure if that's being maintained or if it works.)

[obskyr]

Does implementing lookahead / lookbehind worsen performance for expressions that don't use them?

[BurntSushi]

No.

[obskyr]

Hmm... Maybe it'd make sense to implement them, then? To achieve compatibility with other regex engines and with people's expectations.

[BurntSushi]

There is a reasonable case that someone could make for that, sure. But it's mostly theoretical. You also need to find someone willing to do it. (And by that, I mean, "someone willing to write the code, maintain it and do the necessary API design work." It is significant.) You also need to provide a compelling argument that the added complexity is worth it. For example, "If I want to run a regular expression supplied by an end user and I want to be sure that it completes in a reasonable amount of time, how can I do that?" The answer today is, "that's already true."

I probably won't comment much more on this. Plenty of other people have made arguments for and against these features on the Internet. Both sides are reasonable.

[obskyr]

Ah, right, regexes supplied by users. You're right, hat's a consideration. One possibility is to provide an option for turning off features that may increase run time significantly, or a feature to detect whether they're present beforehand.

As for "maintain it"... there's already someone who maintains the regex package, I hope. And as for API design work, that's not really significant at all, is it? Sure, deciding whether and if so how to handle shutting off the "slow" features might take a bit of consideration, but beyond that there's no extra API design to do at all. The main (only?) real point is that you have to find someone to write the code. Which of course isn't trivial at all, but I don't think entirely foregoing very common features (I'd even dare to say they're expected) for performance is the right choice.

[BurntSushi]

there's already someone who maintains the regex package

Yes. That's me. :-)

And as for API design work, that's not really significant at all, is it?

I included a lot more than API design work in my previous comment.

(I'd even dare to say they're expected) for performance is the right choice.

I disagree. So do a lot of people. Predictable performance is important.

I don't think we're going to get very far with this. Here are the facts on the ground:

1. There are no plans to add lookaround or any other features that lead to hard-to-predict performance. Even if there were, the time scale for that happening would be "years."
2. If you want fancier features, you might elect to just use PCRE2, or, if you want a pure Rust solution, you could use the fancy-regex crate (which is built on this one).