On Mon, Jun 22, 2026 at 6:59 PM Juliette Reinders Folmer < [email protected]> wrote:
> On 22-6-2026 15:13, Gina P. Banyard wrote: > > It is this time of year again where we proposed a list of deprecations to add > in PHP 8.6: > https://wiki.php.net/rfc/deprecations_php_8_6 > > > Hi Gina, thanks for working on this. > > Unfortunately none of the proposals contain a proper impact analysis. > > I don't hold this against you personally, I know this RFC is the work of > quite a few people, but I do find it terribly irresponsible that the impact > of these deprecations is not outlined for the voters to help their decision > making. > > In my experience, it would be quite trivial to create an impact analysis > for the fast majority (~70%) of the current proposals using PHP_CodeSniffer > and PHPCompatibility. > > I'd be happy to help get that set up if there is interest in adding such > an analysis to the proposals. > > Smile, > Juliette > > Hi Juliette, Thanks for raising this. For the *return-in-finally deprecation*, I did run an impact analysis. I just kept it out of the RFC entry itself, partly to keep the entry short, partly because I'd already shared the core of it in my original pre-RFC message on this list ( https://externals.io/message/131393#131393 - which lists all 12 affected sites), and partly because I hadn't gotten around to reposting it in this thread yet. So here it is, for you and for anyone else following along... I compiled the ~5000 most-installed Composer packages with the patched build and collected every site that triggers the new deprecation. It shows up in 12 places across 9 packages, about 0.18%. Reading each one: - 3 are latent bugs the deprecation would catch, where the finally return discards an exception the try can throw - the other 9 either deliberately rely on the discard or are harmless The full write-up, with the per-site breakdown and the script to reproduce it, is here: https://github.com/aldemeery/php-rfcs/tree/master/deprecate-return-in-finally Thanks, Osama
