Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128252
Date: Mon, 28 Jul 2025 10:33:53 +0000
To: Niels Dossche <dossche.niels@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] pcre extended character class support
Message-ID: <vyeiYhEpTw7KnbU1vFM0tEKsRPNUhR3WFzCSxir_NbBtKuv90bFSCv-mQRZoEt8nZlrep1N4ZjhmRsOuoXayFa64nA3nEE7emUk9YLeyA90=@gpb.moe>
In-Reply-To: <7f892c24-8eef-4238-844a-5dde7f5a536d@gmail.com>
References: <7f892c24-8eef-4238-844a-5dde7f5a536d@gmail.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Friday, 25 July 2025 at 23:20, Niels Dossche <dossche.niels@gmail.com> w=
rote:

> Hi internals
>=20
> On PHP 8.5-dev, we ship with pcre2lib 10.45.
>=20
> This includes a new opt-in feature called "PCRE2_ALT_EXTENDED_CLASS".
> It enables the use of complex character set operations in accordance to U=
TS#18 (Unicode Technical Standard 18).
> This means it becomes possible to nest character sets, perform set operat=
ions on them, etc.
> One example of such a set operation is a set subtraction, e.g. the regex =
"[\ep{L}--[QW]]" means "Unicode letters other than Q and W".
> Or a more realistic example (inspired from [1]): the regex "[\p{Lu}--[0-9=
]]" matches all non-ASCII unicode numbers.
> You can also do ORs, ANDs, etc.
>=20
> The reason this is opt-in in pcre2lib, is because the interpretation of e=
xisting regexes may change.
> This standard is being adopted in other languages too, also opt-in, for e=
xample in JavaScript [1].
> To expose this functionality in PHP, we also have to make it opt-in via a=
 modifier.
>=20
> In JavaScript, this is enabled via the /v modifier at the end of the rege=
x [1].
> This does the same thing as the /u modifier, but extends it with this UTS=
#18 standard.
> We also already have /u in PHP that enables UTF-8 unicode mode. So we cou=
ld do the same as JavaScript and add a /v modifier that extends /u and also=
 enables PCRE2_ALT_EXTENDED_CLASS. Technically, you don't need unicode proc=
essing for enabling PCRE2_ALT_EXTENDED_CLASS, but as it comes from a unicod=
e standard (and that at least JavaScript does this too), it may make sense =
to enable them both.
>=20
> The actual patch is trivial:
> `diff diff --git a/ext/pcre/php_pcre.c b/ext/pcre/php_pcre.c index 8e0fb2=
cce5f..4a4727545ad 100644 --- a/ext/pcre/php_pcre.c +++ b/ext/pcre/php_pcre=
.c @@ -718,6 +718,9 @@ PHPAPI pcre_cache_entry* pcre_get_compiled_regex_cac=
he_ex(zend_string *regex, bo case 'S': /* Pass. */ break; case 'X': /* Pass=
. */ break; case 'U': coptions |=3D PCRE2_UNGREEDY; break; +#ifdef PCRE2_AL=
T_EXTENDED_CLASS + case 'v': coptions |=3D PCRE2_ALT_EXTENDED_CLASS; ZEND_F=
ALLTHROUGH; +#endif case 'u': coptions |=3D PCRE2_UTF; /* In PCRE, by defau=
lt, \\d, \\D, \\s, \\S, \\w, and \\W recognize only ASCII characters, even =
in UTF-8 mode. However, this can be changed by setting`
>=20
> What do we think?
>=20
> [1] https://github.com/tc39/proposal-regexp-v-flag
>=20
> Kind regards
> Niels

I'm in favour of this, as this is small and self-contained, I don't think t=
his should require an RFC.

Best regards,

Gina P. Banyard