Re: Pre-RFC: adding a Regex\CompiledRegex class for compiling regular expressions

Hey, Overall very positive about this, the preg_ functions are full of foot guns. I've worked on https://github.com/composer/pcre#basic-usage which adds some type safety / strictness to the whole thing, and could maybe be of some inspiration for the API although some things I had to do because of limitations of the underlying or phpstan at the time, so it's not all perfect by any means. On 25.09.2026 18:19, Larry Garfield wrote:

How would this Match object work? What is it's API? And if you don't care about captured groups why would you need to instantiate an (or multiple) object when a boolean value would do just fine. That's why I said I don't want to spend time on designing an API as this frankly needs multiple methods and is going to be complicated. There are also new PCRE2 features not exposed to userland where it may make sense to do so in a greenfield API.

That feels like two separate methods then. match(): bool and matchCapture(): MatchResult, or something like that.

FWIW composer/pcre has isMatch(): bool and match(): MatchResult (see https://github.com/composer/pcre/blob/main/src/MatchResult.php)

Arguably we have named parameters to just toggle the options that are different from the default, so I wouldn't be writing a call to it like this nowadays anyway. But Nora did suggest an array of enum RegexOptions on the PR, and my reply was that if PHP had a way to pass an Enum set this would be the best approach as you'd only have one parameter. In any case I don't have strong feelings about this part (or maybe I should spend some time and figure out a way to make enum sets a reality before)

If we can make sets a native type with good operator usage (I have designs for this), then enum sets would fall out naturally. Baring that, I assumed this would always be called with sparse named arguments, which I am fine with. (As someone who rarely uses regexes, admittedly.)

I'd really like to still have a way to pass a string with modifiers like JS has new RegExp("ab+c", "i"), because these modifier are hardwired in many people's brains, but it could also be an alternative factory method rather than overloading the second param. And finally to correct a point from the OP Gina:

The $pattern parameter removes the need to use a delimiter, and a potential call to preg_quote()

I do not think the latter is true. We still need to quote if you pass untrusted input, or just are otherwise unsure what's in a string. And having Regex::escape() would make sense I guess. Best, Jordi -- Jordi Boggiano @seldaek -https://seld.be