Re: [PHP-DEV] [RFC] Deprecations for PHP 8.6 [impact scans]

On 16.07.26 05:44, Juliette Reinders Folmer wrote:
> 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
>
Thanks for that. I added them for y'all to the RFC text (after being in 
touch with Gina and Tim for similar edits).

---

Cheers
Nick