Re: BC break in master (7.2) - Distinguish between unmatched subpatterns and empty matches in preg_*()

From: Date: Mon, 15 May 2017 15:21:23 +0000
Subject: Re: BC break in master (7.2) - Distinguish between unmatched subpatterns and empty matches in preg_*()
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-99046@lists.php.net to get a copy of this message
On Mon, May 15, 2017 at 6:36 AM, Nicolas Grekas <nicolas.grekas@gmail.com> wrote: >> I agree that a minimum 5 years old possible bug, quite small, causing >> BC breaks is not good. As far as the fix is critical or justified, I >> think it is sometimes ok to break BC for edge cases. However I do not >> see this is not the case here. >> > > Another possibility would be to make this opt-in, with a new flag. > FYI, I quickly spotted at least two places in the code base where we check > the matches with something like: > > if ('' !== $matches[2]) {...} else {...} > > This should be a pretty common check so the BC break will impact more > userland code when released. > I agree with the original bug report that being able to distinguish between not-matched and empty-match is a useful and meaningful distinction, and since most users won't care, then the decision to just do it was *probably* right at the time. Given the observation about strict equality checks (which I don't have the data for, but it rings true) it does seem optimistic in *handsight*. Given that, I'd recommend a middle-ground such as the opt-in behavior described here. The extra effort to add that option flag in the rare handful of cases where it matters is miniscule compared to the cost of adjusting equality checks in the myriad places where it doesn't matter, but shows up. My 2 ¢ -Sara

« previous php.internals (#99046) next »