> > > It also makes the `FILTER_VALIDATE_REGEX_PATTERN` flag highly ambiguous as > > it is unclear against which engine/dialect the regex would be validated. > > Indeed, the multi-engine "issue" makes it clear that it would be ambiguous. > > > Maybe the error code flags returned via `preg_last_error()` [4] should be > > made more specific to allow for detecting when a regex function failed due > > to an error in the regex. > > Maybe the extensions should get a "throw on invalid regex" option, either > > via an ini flag, a new function parameter or via an existing function like > > `mb_regex_set_options()`. > > I like the first solution, I like the second one even more. It would > be aligned with JSON_THROW_ON_ERROR. >
I completely agree with this and the previous reply from Juliette. I'm familiar with the upstream PCRE2 library, and they have made several changes to the regex rules/syntax within the past couple years. Unless the validation is made within the same realm of the engine, it will have to be validated by the engine itself if we want the validation to be accurate to the rules supported by the engine. A `PREG_THROW_ON_ERROR` flag would be the best of both worlds: - Provides a nice safe-guard against potentially invalid regexps and surfaces them up as an exception. - Provides validation functionality with engine-provided error messages. - We do not need to keep up with the regex engines because validation is done by the engine. - Works similar to the `JSON_THROW_ON_ERROR` flag.
