On 22-6-2026 17:58, Juliette Reinders Folmer 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
All,
I've previously spoken up about the lack of impact assessment/analysis
for the vast majority of the proposed deprecations and offered to run
some PHPCompatibility scans.
Here are the results of these scans. Please keep the below caveats in
mind when interpreting these assessments.
=== Caveats:
* Some RFC texts already contained results of independent impact
scans. Thanks for that!
I've still included (some of) those proposals in the currently
executed scans to have a set of findings which have been prepared in
the same way and are therefore comparable.
* The Packagist Top 4000 is not representative of PHP code in general.
Most of these projects are well maintained and have a high standard
for code quality, so it is very well possible that the functionality
occurs more frequently in private projects, especially in less well
maintained projects.
* These scans do not give any indication about the amount of work it
may, or may not, be to update projects to deal with the deprecations
and prepare for PHP 9.0. It also gives no indication how those updates
will further impact downstream projects.
* The scan results have not been de-duplicated or individually
validated, they are based on the raw scan results. These raw scan
results are available in the linked gists for anyone who wants to
review them.
* While PHPCompatibility has a pretty high level of accuracy, both
false positives as well as false negatives can occur. I have not
validated each individual find. Please report false positives to the
PHPCompatibility project [1] to help improve the underlying logic in
the sniffs.
N.B.: one known false positive, of which it is unclear/not
validated whether it occurs in the scan results, is when an imported
namespaced function mirrors the name of a PHP global function.
* The PHPCompatibility warning messages shown in the "code" reports
are subject to change if a proposal would pass and may not currently
be precise enough.
=== Scan results:
Based on a scan of the Packagist Top 4000 (446.664 files) per July
2nd, I can see the following number of occurrences for the following
proposed deprecations:
Deprecate the list() construct: 12.275 occurrences in 5.545 files
Full details:
https://gist.github.com/jrfnl/9ca4af66f31c5afd08a4598ae73c0ded
Deprecate return from finally: 8 occurrences
Full details:
https://gist.github.com/jrfnl/7902d86aa5d6b306e0edad9d7c1ff274
Deprecate identifier "let": 3 occurrences
Full details:
https://gist.github.com/jrfnl/e540ce964e348d5ab6ebf07937763173
Deprecate namespace as class constant or static property: 21 occurrences
Full details:
https://gist.github.com/jrfnl/a23b568f7b99775a1a3434e7176ced48
Deprecate identifiers in/out/inout: 33 occurrences
in 25 (includes Doctrine, Laminas, Laravel and Magento)
out 8
inout 0
Full details:
https://gist.github.com/jrfnl/9c1430200757daa529b5f9b667585b10
Deprecate identifier "is": 9 occurrences
Full details:
https://gist.github.com/jrfnl/49ee0a1b863d56e85b8b4b18bbcc79c9
Deprecate identifier readonly as function: 2 occurrences
Full details:
https://gist.github.com/jrfnl/fb680994d2d6f99c36e68a710fc2740d
Deprecate _ as constant/compile time alias: 7 occurrences
Full details:
https://gist.github.com/jrfnl/f7ad1aad5842187e44c16be2f34ad9eb
Deprecate _ as function name and the _() function: 4 + 96 occurrences
Full details:
https://gist.github.com/jrfnl/f7ad1aad5842187e44c16be2f34ad9eb +
https://gist.github.com/jrfnl/bf2b5fb4ef1f836db2d8d84ee4828dc2
Deprecate is_double(): 35 occurrences
Full details:
https://gist.github.com/jrfnl/e646412ca381ea0feca27604e713af0b
Deprecate is_integer(): 303 occurrences
Full details:
https://gist.github.com/jrfnl/90cede1a93ddb217123c5ff9e6b3dbb6
Deprecate is_long(): 16 occurrences
Full details:
https://gist.github.com/jrfnl/27b7b20240c6ebc2a227130d0367d108
Deprecate doubleval(): 8 occurrences
Full details:
https://gist.github.com/jrfnl/c6df988ab223d0e905e4d6c9a18da8cc
Deprecate define() $case_insensitive: 42 occurrences
Full details:
https://gist.github.com/jrfnl/610c5c0c21f1ff45d1932ba1f49bf621
Deprecate is_subclass_of() with string and $allow_string false: 0
occurrences
Full details:
https://gist.github.com/jrfnl/6c95a9b2408bee1a1e85e1629de6a2fd
Deprecate is_a() with string and $allow_string false: 0 occurrences
Full details:
https://gist.github.com/jrfnl/17c0dc1d402ea97eec887a96b117f9be
Deprecate strcoll(): 11 occurrences
Full details:
https://gist.github.com/jrfnl/28c192b1f2a1fa1ae06b9df9646c1da5
Deprecate SORT_LOCALE_STRING: 17 occurrences
Full details:
https://gist.github.com/jrfnl/3ef53816ec959e53a7d86b6dbb1f900e
Deprecate metaphone(): 9 occurrences
Full details:
https://gist.github.com/jrfnl/cc0221a1de954b6c7fa8d26da3fbab28
Deprecate spl_classes(): 0 occurrences
Full details:
https://gist.github.com/jrfnl/8a0231930956a66e7c4f316dd44c515c
Deprecate spl_object_hash(): 625 occurrences
Full details:
https://gist.github.com/jrfnl/6ff4e1316d58b98e15f82d1ce33a565d
Deprecate mysqli_stmt_init() (scanned for procedural calls only): 0
occurrences
Full details:
https://gist.github.com/jrfnl/8dff0f35070a13ab4dd3d6e03acb6874
Deprecate mysqli_get_charset(): 0 occurrences
Full details:
https://gist.github.com/jrfnl/d3358fee835bd75ed25b23be46541a91
=== Regarding updating the RFC texts:
While I would regard adding a text snippet about the scan results and
a reference to the applicable gists to the various RFC texts as a
minor change, Gina's mail from Monday stated that the RFC text should
be considered frozen, so I defer to Gina to decide whether any of the
above information should/can still be included in the RFC texts.
If so, and if you are the author of one of the proposed deprecations
which doesn't have any kind of impact assessment yet, please consider
validating the scan results applicable to your proposal(s) and adding
some information to the RFC text about the potential impact of your
proposal.
=== Other observations/feedback on the RFC texts:
* Re: `list()` deprecation - tooling like PHP_CodeSniffer can also
perform this conversion (for example, via the PHPCSExtra
`Universal.Lists.DisallowLongListSyntax` sniff [2]) and I suspect will
yield higher accuracy than the regex.
Having said that, I'm definitely not in favour of deprecating
`list()`.
* While listed in the "introduction" section, there is no section for
the "Deprecate changing by-reference return modifier via inheritance"
deprecation.
* The "Deprecate mysqli::stmt_init" deprecation does not mention the
procedural `mysqli_stmt_init()` function, while I presume that will be
deprecated too ?
Either way, I hope this information helps the voters in their
contemplations about the proposals.
Smile,
Juliette
1: https://github.com/PHPCompatibility/PHPCompatibility
2:
https://github.com/PHPCSStandards/PHPCSExtra#universallistsdisallowlonglistsyntax-wrench-books
