Will look-around be supported one day?

[frederikhors]

I'm trying to use this regex but I get an error from clippy:

Regex::new(r"^[ \t]+|[ \t]+$|[ \t]+(?=[ \t])/mg").unwrap()

regex syntax error: look-around, including look-ahead and look-behind, is not supported
`#[deny(clippy::invalid_regex)]` on by default
for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#invalid_regex

Why?

[BurntSushi]

To the degree I can be certain about anything, I'd say no, general look-around will never be supported. From the first paragraph of the crate docs (emphasis mine):

This crate provides a library for parsing, compiling, and executing regular expressions. Its syntax is similar to Perl-style regular expressions, but lacks a few features like look around and backreferences. In exchange, all searches execute in linear time with respect to the size of the regular expression and search text.

See also: #855, #853, #716, #666, #618

And from RE2, the regex crate's ancesor: google/re2#156, google/re2#365, google/re2#269

The wording above isn't quite precisely correct, but the general idea is that it isn't known how to implement arbitrary look-around in an efficient manner. The regex crate does support some very limited look-around in the form of ^, $ and \b. There aren't any plans to expand beyond that. Note that fancy-regex is a crate that builds on top of regex and provides features like backreferences and look-around. So you can always use that.

[blyxyas]

I think that a lot of users don't really care about linear time if look-around and back references are supported. I feel like that is a pretty worth it exchange.

[BurntSushi]

The great thing is that a single regex engine doesn't need to be all things to all people. This particular regex engine emphasizes a focus on bounded performance. If you don't care about bounded performance, then you can use a different regex engine. fancy-regex is, for example, built on top of the regex crate and gives you those extra features.