On 23/09/2026 9:01 pm, Gina P. Banyard wrote:
Hello internals,
I spent the day prototyping an alternative to the PREG_THROW_ON_ERROR RFC as
I'm not fully a fan of the approach.
Hi Gina,
Thank you for sharing this idea. As this would get rid of the ugly
delimiters, which means that I can finally copy-paste regexes from the
Regex app I use on a regular basis without having to consider slashes,
pipes or anything what comes to mind.
I initially thought of something like this:
public function __construct(string $pattern, int $modifiers = 0) {}
with all the different PCRE2_* modifiers exposed as class constants but it felt
clunky and seems hard to pre-validate the flag combinations.
Agreed, but having a constructor that takes 9 parameters doesn't feel
great as well IMHO. To the eye of a developer, who usually doesn't fully
understand PCRE2 most of these parameters will be unfamiliar to them. If
we do add these to the constructor, could we at least try to match the
PRCE constants? E.g greedy would then become ungreedy (PCRE_UNGREEDY).
For the prototype I've only added support to use this new class to the
preg_split() and preg_grep() functions as they were easy to tweak.
Is it by design that this class does not have a `__toString()` method.
And would you consider adding it? It would potentially allow the stubs
for the exiting functions to stay unchanged. This would be similar to
what the Uri API is doing, however it would require some sort delimiter
generation I suppose.
And if we are going that direction, how about we add a `::fromString()`,
to make it easier to migrate to this new API? And make use of it's
Validation ability.
--
Regards,
Jordi Kroon
