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

[andrew-d]

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

[BurntSushi]

Sounds like a fine motivation for exposing some of the internals! A few notes...

I think the primary issue with exposing the internals is, if we expose something, will we need to eventually make a stability guarantee about the things we're exposing? Or can it just be marked experimental for the foreseeable future?

The existing regex implementation is, frankly, a first draft in terms of performance. There is still room for a lot of performance improvement, and it isn't clear to me how this may or may not change the internals.

I would also strongly suggest that if we expose any internals, that they be exposed via a sub-module so as not to interfere with the real public interface.

[andrew-d]

I think it'd be fine to expose the internals as #[experimental] for the foreseeable future - I suspect most people won't be using the internals anyway, frankly. Exposing them as a submodule also sounds like a good idea 😄

[rust-highfive]

This issue has been moved to the regex repo: rust-lang/regex#29