New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distinguish between unmatched subpatterns and empty matches in preg_*() #1303
Conversation
I think this makes sense. |
* pull-request/1303: Distinguish between unmatched subpatterns and empty matches in preg_*() news entry for PR #1303
Thanks :) |
This needs a note in UPGRADING, as it's BC breaking. |
Done with commit c832ab4. |
Fixed bug introduced by preg_match change from php/php-src#1303
BC break, but why? Seriously, not again. |
Documenting BC breaks is not enough - the policy is not to have them outside major versions. Why not add a flag that controls this behaviour? |
Agreed, another useless BC break in minor version. Please rather introduce something opt-in like PREG_SUBPATTERN_UNMATCHED_NULL (or whatever better) that could be turned on by default in next major version. |
Is this behaviour going to stay? or will it change to something BC? |
This already breaks Symfony: symfony/symfony#22667 |
See #2526 to make this opt-in, removing the BC break. |
Currently it is not easily possible to distinguish between unmatched subpatterns (i.e. unset substrings) and empty matches in preg_match(_all); in both cases an empty string is yielded. Using PREG_OFFSET_CAPTURE makes that possible (negative offset indicate unmatched subpatterns), but that seems to be unnecessarily clumsy.
In bug #61780 it has been proposed not to set the respective keys in $matches, but that might be too big a BC break even for PHP 7.0.0. Setting those to NULL, however, might be acceptable, and would still allow to distinguish between the two cases (even with isset). Therefore I think this PR would resolve bug #61780.