Re: [DISCUSSION] Deprecate mbregex in PHP 8.6 and maintenance version

2025年8月26日(火) 19:15 Derick Rethans <derick@php.net>: > > On Mon, 25 Aug 2025, Christoph M. Becker wrote: > > > On 25.08.2025 at 09:26, youkidearitai wrote: > > > > > I improvement this RFC. > > > https://wiki.php.net/rfc/eol-oniguruma > > > > > > Added more information about maintenance versions. What do you think > > > about Oniguruma maintenance ended. Please watch and feel free to > > > comment. > > > > First, thank you for caring about this! I agree that we need a long > > term solution for this issue. As I understand it, Oniguruma's > > greatest advantage over PCRE2 is that it supports other character > > encodings than Unicode and ANSI, so deprecating mbregex might be a > > problem for some users. > > Yes, but I think Yuya mentioned somewhere else (I can't find it now) in > an earlier discussion, that many of these users now also moved to UTF-8. > It would also be possible to rewrite these uses from using mbregex to > UConverter::convert+pcre. > > Incidently, icu also has a regular expression engine, but of course > that'll operate on UTF-16, and we'd have to create a full new > implementation for that: > > - > https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/uregex_8h.html > > > Still, the alternative would likely be to bundle liboniguruma, and I > > don't think that would be a good idea. So deprecating mbregex as of > > PHP 8.6.0 seems prudent; if there would be lots of objections, we > > could still reconsider. > > I agree with that. > > > Now I wonder how much trouble it would be to separate mbregex from > > ext-mbstring. If that can be done with a reasonable amount of work, > > that would likely be the best course of action (in addition to > > deprecating mbregex). We could than move the extension to PECL/PIE, > > and let users deal with it (I'm not happy what happened to ext-imap, > > but it's still better than relying on an unmaintained library from a > > bundled extension). > > Seeing code like in mbstring.c > > #ifdef HAVE_MBREGEX > PHP_MINIT(mb_regex) (INIT_FUNC_ARGS_PASSTHRU); > #endif > > And: > > php_mbregex.h:PHP_MINIT_FUNCTION(mb_regex); > php_mbregex.h:PHP_MSHUTDOWN_FUNCTION(mb_regex); > php_mbregex.h:PHP_RINIT_FUNCTION(mb_regex); > php_mbregex.h:PHP_RSHUTDOWN_FUNCTION(mb_regex); > php_mbregex.h:PHP_MINFO_FUNCTION(mb_regex); > > makes it feel that it already sort-of operates as a sub-extension, and > it wouldn't be *too* much work. But it will still be work. Is it worth > it? > > cheers, > Derick > -- > https://derickrethans.nl | > https://xdebug.org | https://dram.io > > Author of Xdebug. Like it? Consider supporting me: > https://xdebug.org/support > > mastodon: @derickr@phpc.social @xdebug@phpc.social Hi, Internals I created extension mb_onig that separate mbregex functions. This package include Oniguruma that my update(Unicode 17.0). https://packagist.org/packages/mb_onig/mb_onig (This package is experimental) With this idea, I think it would be good to separate mbregex. What do you think? Regards Yuya -- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------