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
