Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99034
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.48 as permitted sender)
MIME-Version: 1.0
Sender: kalle.php@gmail.com
In-Reply-To: <CAOWwgpm3Sq0nLeVcgXdGAjtcaQGuLgK=oTJRWFvQay4dDUWiXw@mail.gmail.com>
References: <CAOWwgpm3Sq0nLeVcgXdGAjtcaQGuLgK=oTJRWFvQay4dDUWiXw@mail.gmail.com>
Date: Mon, 15 May 2017 09:21:46 +0200
Message-ID: <CAJW__o309eGo0_ZOdmOJ13pyZN=WN4aiUEk4+Mn+QemXA7DX5A@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] BC break in master (7.2) - Distinguish between
 unmatched subpatterns and empty matches in preg_*()
From: kalle@php.net (Kalle Sommer Nielsen)

Hello Nicolas

2017-05-15 8:57 GMT+02:00 Nicolas Grekas <nicolas.grekas@gmail.com>:
> Hi,
>
> in master, feature request https://bugs.php.net/61780 has been implemented
> and merged into master thanks to https://github.com/php/php-src/pull/1303
>
> But as noted in the PR and even in the UPGRADING file, this is a BC break:
>   . preg_match() and other PCRE functions now distinguish between unmatched
>     subpatterns and empty matches by reporting NULL and "" (empty string),
>     respectively. Formerly, either was reported as empty string.
>
> While trying to run Symfony's test suite against 7.2, we noticed that this
> BC break is hitting several components badly. If Symfony is hit, there will
> be many more userland code impacted for sure.
>
> As written explicitly in the releasing policy of php-src, BC breaks must
> not happen in minor versions. Therefore, I'm kindly but strongly asking for
> this BC break to be reconsidered and removed.

Generally we do trend to break BC in release versions. Take 7.1 for example:

            call_user_func('extract', ['name' => 'Rasmus']);

Is no longer legal, tho I do wonder who would be insane enough to do
something like that, but some changes are for the better of all of us,
I would personally call these quality of life changes. Or the notice
for applying an arithmetic operation on an poor formatted integer,
also in 7.1:

            var_dump(2 + '5 apples');

Now for this change in particular, it was in the PR tracker for almost
8 months before it was merged and there was one comment that was a
positive one to it. Now don't get me wrong here, it is not everyone
that actively develops PHP and follows, tests and play with everything
submitted to us, but it was first over 2 months after it was merged,
that users started to react to this change instead of simply updating
tests, like this guy[1] did before any "BC Break" comments was let
out. It could even be simpler, it seems more like it to me, that we
spend more time discussing the politics than actually just fixing the
code so, as it can easily be done to be backwards compatible in
multiple ways.

When that is said, I can totally understand the frustration it causes
that something breaks, but I think we should see the over all picture
for each individual change, and this one is a good quality of life
change to me (and other core developers too it seems). Had it been
something major, I could understand that you'd wish it be reverted,
but this is so minor that we shouldn't waste more keystrokes on it.

[1] https://github.com/squizlabs/PHP_CodeSniffer/commit/d397f87d58119cd04cba1bc4dda1216ebb9ba642

-- 
regards,

Kalle Sommer Nielsen
kalle@php.net