future of GRegex
Submitted by Christian Persch
GLib uses PCRE for its regex support. There are a number of problems that need to be addressed:
GLib embeds an old copy of PCRE; it needs to go away. This is already being discussed in #962.
GLib's PCRE support is at level of PCRE 8.31, a very old version, so it's missing the additions since then; #642 is about updating it. And the corresponding wip/pcre-update branch is up to 8.35 (iirc?).
GLib doesn't allow using PCRE's JIT which speeds up matching, #566.
PCRE itself is deprecated in favour of a new API called PCRE2. The old PCRE will only receive sporadic bugfix releases for a some time.
So there needs to be a fundamental decision about what to do with GRegex. I think these are the alternatives:
[A] . (Least work) Deprecate GRegex (and perhaps later remove it) and recommend users to use PCRE2 directly.
[A'] Deprecate GRegex, drop PCRE use internally making GRegex a no-op (i.e. always return NULL and error from g_regex_new). Might be considered an ABI break.
[B] Update GRegex to use PCRE2 internally (and expose the JIT functionality).
[C] A and B.