[feature request] Expose libregex's parsing/compiling internals

[rust-highfive]

Issue by andrew-d
Thursday Nov 06, 2014 at 19:54 GMT

For earlier discussion, see rust-lang/rust#18710

This issue was labelled with: in the Rust repository

---

I was looking at implementing something similar to this - a trigram-index-aided search. I'd rather not reproduce the code necessary to parse the regex, considering it already lives in libregex. It'd be nice if the parsing/compiling was exposed for use - perhaps similar to how Go does it with their regexp and regexp/syntax packages.

cc @BurntSushi

[andrew-d]

Should be closed - see #23

[BurntSushi]

So I've gotten more requests to do this and I'm also somewhat interested in it myself. Regex parsing is not easy and it has uses beyond the matching supported in crate.

@alexcrichton I know you were kind of down on this last time we talked about it, but what if we split the parsing into its own separate crate? (In this repository.) That way, we can keep the main regex crate stable even if the parser has a breaking change. The major version on the parser might increase more rapidly than regex, but I think I'd be OK with that since it would not be as widely used as regex proper.

[alexcrichton]

Creating a separate crate for the parser sounds like a great idea to me!

[BurntSushi]

I'm currently working on this in the new-parser branch. I'm rewriting the parser and tweaking the AST a bit before releasing it as a separate crate.