Anchor to start with is_match_at

[jdoege]

is_match_at starts matching at a specified offset in the provided string. However it uses the anchors /A to match to the beginning of the string and ^ at the beginning of the a line. How can we anchor is_match_at to the start point? To have the following produce a match, for instance:

extern crate regex;
use regex::Regex;

fn main() {
    let re = Regex::new(r"^\w{5}").unwrap();
    let text = " Hello";
    println!("Found match? {}", re.is_match_at(text,1));
}

Other regex libraries (Python in particular) support this behavior and it is quite useful for parsing large files.

[BurntSushi]

Can you say why you need to use is_match_at here? Try this instead:

use regex::Regex;

fn main() {
    let re = Regex::new(r"^\w{5}").unwrap();
    let text = " Hello";
    println!("Found match? {}", re.is_match(&text[1..]));
}

[jdoege]

That solves my problem that way, thank you; but it suggests the question, what is is_match_at for, then, if this is the way to start a match at a position?

[BurntSushi]

Right, my answer is somewhat narrow. It solves the specific problem you've posed, but is_match_at does provide a power that cannot be achieved via the is_match API. Specifically, in order to implement correct iteration of matches, you need is_match_at. Consider the regex X|\bfoo\b and consider haystack = "Xfoo". The first search will report X as a match. Now you need to look for the next match. How do you do it? You can't just do find(&haystack[1..]). Notice that it will erroneously report a match because the regex engine considers the beginning of the haystack to be a word boundary. But &haystack[1..] is not the beginning of the haystack, and indeed, there is no word boundary between X and foo. So something like find_at(haystack, 1) is actually needed, so that the regex engine can "see" the surrounding context of where the search starts in order to correctly match look-around assertions.

If it weren't for look-around assertions (that's ^, $ and $), then I believe it is correct to say that the *_at APIs don't give any extra power and are never necessary.

Of course, the regex crate provides iterators for you, so you don't need to implement them yourself. Therefore, it's somewhat rare to need the *_at APIs.

With all that said, the *_at APIs were poor design on my part. They permit providing the starting point of the search, but not the ending point of the search, which is necessary in some cases too (although not for iteration).

The thing you're asking about is basically whether it is possible to run an anchored search without using ^. In particular, ^ only matches at offset 0. So any regex beginning with ^ will fundamentally never produce true when you call is_match_at(haystack, N) where N > 0. In contrast, an anchored search (which can be done with any regex), might produce a match for N > 0, but the guarantee you get is that if a match is returned, then its starting offset is N. So, when you use is_match, an "anchored" search and a search with a regex with a ^ anchor are indistinguishable because N = 0 in that case. But once you're able to set the starting offset of the search, the meaning of "anchored" and ^ diverges.

Indeed, the regex API does not let you execute an anchored search for N > 0. I don't know if it ever will, but once #656 lands, regex-automata will dis-entangle all of these things. That doesn't mean regex itself will, but there will be lower level APIs that do. See Input::anchored and Input::span. Both of those APIs include real examples that might aide understanding as well.