Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Deprecations for PHP 8.6 »

[RFC] Deprecations for PHP 8.6

php.internals

Gina P. Banyard

71 days ago
Hello internals, 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 As a reminder, this list has been compiled over the course of the past year by different people. And as usual, each deprecation will be voted in isolation. We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. Please note that with the new RFC policy rules the RFC must be finalized and in a "frozen" state by the 13th of July at the latest. Some deprecations should be non-controversial, others a bit more. If a deprecation is really controversial, it might warrant its own dedicated RFC or be dropped altogether. Best regards, Gina P. Banyard

Nicolas Grekas

71 days ago
Hi Gina, Le lun. 22 juin 2026, 15:19, Gina P. Banyard <internals@gpb.moe> a écrit :
> Hello internals, > > 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 > > As a reminder, this list has been compiled over the course of the past > year by different people. > > And as usual, each deprecation will be voted in isolation. > > We still have a bit of time anyone else to propose additional > deprecations, and if you have write access feel free to add them directly > to the RFC. > Please note that with the new RFC policy rules the RFC must be finalized > and in a "frozen" state by the 13th of July at the latest. > > Some deprecations should be non-controversial, others a bit more. > If a deprecation is really controversial, it might warrant its own > dedicated RFC or be dropped altogether. > > > Best regards, > > Gina P. Banyard >
After a quick check, I'm wondering about
> Deprecate CURLOPT_PROGRESSFUNCTION for curl_setopt()
Can you expand on this? Thanks, Nicolas

Unnamed Person

71 days ago
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

Osama Aldemeery

71 days ago
On Mon, Jun 22, 2026 at 6:59 PM Juliette Reinders Folmer < php-internals_nospam@adviesenzo.nl> 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

Unnamed Person

70 days ago
On 22-6-2026 20:41, Osama Aldemeery wrote:
> On Mon, Jun 22, 2026 at 6:59 PM Juliette Reinders Folmer > <php-internals_nospam@adviesenzo.nl > <mailto:php-internals_nospam@adviesenzo.nl>> 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 > > Unfortunately none of the proposals contain a proper impact analysis. > > > 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. > ... > 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! And yes, I remember you posting those impact analysis results to the list. I believe it would be good to include that summary in the RFC text. Would make your proposal the (positive) exception to the rule ;-) Smile, Juliette

Tim Düsterhus

70 days ago
Hi On 6/22/26 17:58, Juliette Reinders Folmer wrote:
> Unfortunately none of the proposals contain a proper impact analysis.
Unless your definition of “proper” differs from mine, this is false. As an example, the “Deprecate using "let" as an identifier” deprecation proposal contains this paragraph:
> The analysis performed at part of the let construct (Block Scoping) RFC indicated an insignificant usage of “let” in the wild.
which is more than “none of the proposals”. The same is true for “Deprecate returning from a finally block” proposal. But as every year: - Harmful functionality does not become less harmful, just because it is widely used. - Deprecations are not a breaking change. This is even explicitly written down in the PHP project’s policy as of the https://wiki.php.net/rfc/policy-release-process-update RFC. A majority of the deprecation messages provide actionable advice to the user, and all of the proposals have a proper justification - even if you might personally disagree with it. As an example, I don't personally agree with the deprecation of metaphone(), see https://news-web.php.net/php.internals/130806. Best regards Tim Düsterhus

Unnamed Person

70 days ago
On 22-6-2026 22:54, Tim Düsterhus wrote:
> Hi > > On 6/22/26 17:58, Juliette Reinders Folmer wrote: >> Unfortunately none of the proposals contain a proper impact analysis. > > Unless your definition of “proper” differs from mine, this is false. > As an example, the “Deprecate using "let" as an identifier” > deprecation proposal contains this paragraph: > >> The analysis performed at part of the let construct (Block Scoping) >> RFC indicated an insignificant usage of “let” in the wild. > > which is more than “none of the proposals”. The same is true for > “Deprecate returning from a finally block” proposal. > > But as every year: > > - Harmful functionality does not become less harmful, just because it > is widely used. > - Deprecations are not a breaking change. This is even explicitly > written down in the PHP project’s policy as of the > https://wiki.php.net/rfc/policy-release-process-update RFC. > > A majority of the deprecation messages provide actionable advice to > the user, and all of the proposals have a proper justification - even > if you might personally disagree with it. As an example, I don't > personally agree with the deprecation of metaphone(), see > https://news-web.php.net/php.internals/130806. >
Tim, please don't try to gaslight me. The fact that one out of twentyfive proposals has some vague statement about the impact, without any details of what was analysed or how, without definition of "insignificant", and without a link to details giving credibility to that statement, only goes to highlight that these proposals lack a proper impact analysis. I agree though that the "finally block" proposal is the only positive exception to this. Other than that, I did not express an opinion on the details of the individual proposals, but (as every year) you seem to draw conclusions based on things I never said. The fact that you even feel the need to point out that "deprecations are not a breaking change" is extremely offensive in and of itself. You should know better. Please don't do that. Smile, Juliette

Tim Düsterhus

69 days ago
Hi [reordering the quoted parts for this reply to read more nicely] On 6/22/26 23:41, Juliette Reinders Folmer wrote:
> The fact that you even feel the need to point out that "deprecations > are > not a breaking change" is extremely offensive in and of itself.
It is insofar relevant that deprecations have zero immediate impact. There might be an impact once the actual removal happens, but users have at least 4 years until the PHP version that first made them aware that something is deprecated goes out of (security) support and they might be required to upgrade to a PHP version where the deprecated functionality changed or was removed. It is not unlikely that a product or application will be retired before the four years are over.
> The fact that one out of twentyfive proposals has some vague statement > about the impact, without any details of what was analysed or how, > without definition of "insignificant", and without a link to details > giving credibility to that statement, only goes to highlight that these > proposals lack a proper impact analysis.
The sentence in question contains a link to the RFC where the analysis was made. The “Backward Incompatible Changes” section of that RFC contains concrete numbers. The corresponding RFC discussion - which is linked in the RFC - provides additional information with regard to the methodology (in https://news-web.php.net/php.internals/129074). And generally speaking an “Impact Analysis”, particularly one that is based on analyzing existing code, cannot capture any positive impact the deprecation (and ultimate removal) has on the ecosystem. As an example the “Passing objects which are interpreted as arrays” proposals (which I would count as one) are proposing to deprecate something that is fundamentally broken by allowing to violate core engine assumptions and where straight-forward alternatives are suggested in the deprecation message. This kind of deprecation feels like the PHP-equivalent of passing a law to specifying the ban of sale of Tobacco to folks born after “4 years from now”, which I think some countries already did. Sure this ban will lead to folks in the Tobacco industry losing their job, because of the ever-shrinking market, but they are being provided a 4-year heads-up and some of the employees might even be retired then. And the benefits to the society (and e.g. the health system) far outweigh the drawbacks of keeping the Tobacco industry and associated jobs. And to close the loop to PHP: The core developers are the health workers of the language (and engine) and keeping such a fundamentally broken feature alive means they will have to continue to deal with the most obscure of bug reports resulting from this. For things like deprecating `is_long()`, the positive impact is certainly smaller. But here there is a “positive impact” to be had in making it easier for users to learn PHP. It would be a reasonable interpretation for `is_long()` to mean “a large value” or for `is_double` to mean “is an array containing two elements”. With the expectation that PHP will keep being relevant for the next thirty years and counting and programming being more approachable and relevant than ever, I'd say it's a reasonable claim that there will be more PHP code written in the next 30 years than has been written in the past 30 years and thus something that the benefit to new users is weighing more heavily than the cost to existing users.
> Other than that, I did not express an opinion on the details of the > individual proposals.
I am thus taking issue with the *unconditional* request of an “impact analysis”, which will inherently be biased due to the inability to capture and measure anticipated positive impact and thus will not help make the reader make a more informed decision. Is there some *specific* proposal where you feel there is a stark mismatch between the cost for existing code and the benefit in making the language easier to learn / the benefit in pointing out possible unnoticed mistakes in existing code / the language more maintainable for the core developers and where you feel extra research or justification might be warranted? As Gina said in her email in the PHP 8.4 deprecation discussion (https://news-web.php.net/php.internals/124428): Deprecations are not being proposed because the author gets enjoyment out of causing extra work to PHP users, but because they feel they identified a situation where they can make a positive impact. Best regards Tim Düsterhus

Rowan Tommins [IMSoP]

69 days ago
On 24 June 2026 15:24:38 BST, "Tim Düsterhus" <tim@bastelstu.be> wrote:
>It is insofar relevant that deprecations have zero immediate impact. There might be an impact once the actual removal happens, but users have at least 4 years until the PHP version that first made them aware that something is deprecated goes out of (security) support and they might be required to upgrade to a PHP version where the deprecated functionality changed or was removed.
I hate this argument. Unless otherwise stated, a proposal to deprecate something is a proposal to remove / forbid it in future. The impact analysis being asked for is the impact of that removal / prohibition. That analysis can absolutely account for the fact that removal won't be immediate. For example, maybe all the uses found are in code that will need rewriting for some other reason. Or maybe there's evidence that all the uses found are in fast-moving code that is unlikely to be maintained long term. I don't think anyone is suggesting a threshold where "use in X packages" automatically disqualifies the proposal. We're just asking for the information to weigh the cost and benefit of *the end goal* that the deprecation is trying to achieve.
> I am thus taking issue with the unconditional request of an “impact
analysis”, which will inherently be biased due to the inability to capture and measure anticipated positive impact and thus will not help make the reader make a more informed decision. Bias is inevitable: listing the benefits of changing something without any mention of its impact on existing code is also bias. To knowingly omit information that might weaken your case would be dishonest. If you think the raw numbers don't tell the whole story, it's up to you to explain why. When I proposed to deprecate utf8_encode/decode, I looked into every single usage I could find, so I could make the case that it was used wrong more often than right. Most removals don't need that level of detail, because often some easy numbers *do* tell a clear story.
> Is there some specific proposal where you feel there is a stark > mismatch between the cost for existing code and the benefit in making
the language easier to learn How can anyone answer that question without some information about the cost for existing code? Are you saying that every voter should perform their own research on every proposal? I'm with Juliette on this - any proposal which doesn't have some information about expected impact will get an automatic "No" vote from me. Rowan Tommins [IMSoP]

Tim Düsterhus

68 days ago
Hi Am 2026-06-24 17:29, schrieb Rowan Tommins [IMSoP]:
>> It is insofar relevant that deprecations have zero immediate impact. >> There might be an impact once the actual removal happens, but users >> have at least 4 years until the PHP version that first made them aware >> that something is deprecated goes out of (security) support and they >> might be required to upgrade to a PHP version where the deprecated >> functionality changed or was removed. > > I hate this argument. > > Unless otherwise stated, a proposal to deprecate something is a > proposal to remove / forbid it in future. The impact analysis being > asked for is the impact of that removal / prohibition.
Two years for PHP 8.4 we also had proposals that explicitly specified that no removal was planned for now, that removal would be left to a separate vote and explicit promises about when the removal may happen at the earliest (uniqid and md5/sha1). Back then “just deprecation, no removal” was considered to be an unacceptable impact in discussion and the proposal was ultimately declined. The deprecation period also allows us to obtain *at least* one year of data before the version that does the removal would be released. If it turns out that we missed something during the proposal - e.g. by issues being filed in the tracker, the deprecation can still be reversed and the functionality not actually changed or removed. One example would be the deprecation of __sleep() last year and I seem to remember that someone mentioned before that another deprecation that already shipped also wasn't followed through with a removal and instead be reverted.
> Bias is inevitable: listing the benefits of changing something without > any mention of its impact on existing code is also bias. To knowingly > omit information that might weaken your case would be dishonest. > > If you think the raw numbers don't tell the whole story, it's up to you > to explain why. When I proposed to deprecate utf8_encode/decode, I > looked into every single usage I could find, so I could make the case > that it was used wrong more often than right. Most removals don't need > that level of detail, because often some easy numbers *do* tell a clear > story.
I believe that raw numbers don't tell a correct story for *any* of the proposals and fundamentally can't. Any kind of impact analysis performed by the RFC authors can naturally only account for public code (and their own code) and an analysis on Packagist packages, as usually done, completely disregards anything that is not published on Packagist. An example of the latter would be many applications that while relying on Packagist for their dependencies are not themselves published on Packagist. An analysis on the top X Packagist packages will further be biased towards the big frameworks, which from my experience will have the least trouble to adjust for deprecations. And then of course some proposals are not (practically) analyzable with (naive) static analysis alone, since they will require pulling the entire dependency tree for each package to get the full type information from dependencies. And others require code to already be in a good shape to be analyzable properly, which based on my experience likely is code that has already identified the functionality that is proposed for deprecation as problematic and is thus not affected at all. Given the above, I feel that you might as well roll a dice to come up with a number that would be equally likely to represent the actual situation.
>> Is there some specific proposal where you feel there is a stark >> mismatch between the cost for existing code and the benefit in making > the language easier to learn > > How can anyone answer that question without some information about the > cost for existing code? Are you saying that every voter should perform > their own research on every proposal?
We have a diverse set of voters, many of them with multi-year experience with PHP, Open Source, different employers or clients in case of agencies. I believe that they will be capable of judging the impact appropriately. I've already mentioned how I believe the cost-benefit ratio for `metaphone()` is not good - and you did the same for `_()`. I would agree on your assessment regarding `_()` and will ask Gina to split the deprecation of `_` (the constant) from `_()` (the function) into separate votes. Best regards Tim Düsterhus

Rowan Tommins [IMSoP]

68 days ago
On 25 June 2026 10:17:38 BST, "Tim Düsterhus" <tim@bastelstu.be> wrote:
> If it turns out that we missed something during the proposal - e.g. by issues being filed in the tracker, the deprecation can still be reversed and the functionality not actually changed or removed.
Yes, we will inevitably miss things, and spot them later. A proposal might even account for that by proposing an extra long deprecation period to capture more information. (If we are going to regularly do that, we probably need to keep a register of what we intend to remove when - when 9.0 comes around, I fully expect a large amount of deprecated features to be removed with no further discussion.)
>We have a diverse set of voters, many of them with multi-year experience with PHP, Open Source, different employers or clients in case of agencies. I believe that they will be capable of judging the impact appropriately.
And yes, people might point out things in discussion that the proposer missed, that's all part of the process. But neither of those things make it OK for someone to put forward a proposal without making *some* effort to assess the impact.
> Any kind of impact analysis performed
by the RFC authors can naturally only account for public code (and their own code) and an analysis on Packagist packages, as usually done, completely disregards anything that is not published on Packagist. I think it's still a valuable *first step*, given for many proposals it's pretty easy to do. If there are thousands of public uses, we already know that the impact is likely to be high. If there are a handful of uses, all in a particular context, that can be a clue of *how* people use something. If there are *no* public uses, then we have to do a bit more guesswork, e.g. is it something that's likely to be only in end-user code, so not visible in the check? To me, *all of that* comes under "impact analysis". I totally agree that just putting a number in the RFC isn't all that valuable, but *not even* putting that number in is worse. Regards, Rowan Tommins [IMSoP]

Larry Garfield

68 days ago
On Thu, Jun 25, 2026, at 5:38 AM, Rowan Tommins [IMSoP] wrote:
> I think it's still a valuable *first step*, given for many proposals > it's pretty easy to do. If there are thousands of public uses, we > already know that the impact is likely to be high. If there are a > handful of uses, all in a particular context, that can be a clue of > *how* people use something. > > If there are *no* public uses, then we have to do a bit more guesswork, > e.g. is it something that's likely to be only in end-user code, so not > visible in the check? > > To me, *all of that* comes under "impact analysis". I totally agree > that just putting a number in the RFC isn't all that valuable, but *not > even* putting that number in is worse. > > Regards, > > Rowan Tommins > [IMSoP]
I agree with Rowan and Juliette here. "Seems no one on Packagist is using this" is a useful datapoint. It is not the complete picture, it is not the only data point, and it is not the last word on the subject, but that doesn't make it un-useful. It is just useful-in-context. If other data points are available, great, include them too. The alternative is essentially "let's make a one-sided argument for deprecating something, then see who yells at us loudly in December and writes blog posts about how PHP Internals doesn't care about backward compatibility" Which... is bad press we really don't need, yet again. We can make at least a token effort to minimizing the disruption of deprecations, can't we? --Larry Garfield

Unnamed Person

68 days ago
On 24-6-2026 16:24, Tim Düsterhus wrote:
> ... <snip>.... >
Tim, I've asked you before to not try to gaslight me, but your current mail still does. Your current mail also seems to be largely a response to things I didn't write, so I have no idea what you are trying to do here, other than just sprouting rhetoric which everyone has heard before and nobody is (currently) arguing about. I just offered to help improve the information available regarding the proposals without an opinion about the individual proposals and without voicing an opinion on the principle of deprecations (and for the record: I have no problem with the principle). I have no interest in arguing with you about things which I didn't bring up and which aren't relevant to what I offered. If the justification for a deprecation is strong enough, no impact analysis will be able to stop the deprecation from happening. The only thing the impact analysis can do in that case, is mentally prepare people for the amount of work ahead and inform the decision whether the eventual removal of the feature should be in PHP 9.0, or should be delayed to PHP 10.0. Being against adding an impact analysis for fear of this influencing the vote, is kind of how Brexit happened, which really truly isn't the "golden standard" you seem to think it is.... My offer to help create an impact analysis for the majority of the current deprecation proposals still stands. Anyone who wants to take me up on that, is welcome to ping me. Smile, Juliette

Tim Düsterhus

68 days ago
Hi Am 2026-06-25 07:16, schrieb Juliette Reinders Folmer:
> Tim, I've asked you before to not try to gaslight me, but your current > mail still does.
This is an offensive accusation I struggle with replying to. I don't see a basis for your repeated personal attacks and the (incorrect) factual statement that I would try to gaslight you. I can assure you that this is not the intent of my emails. I have quoted (excerpts of) your emails verbatim and when I reordered the excerpts in the second email I have made that transparent. I have also just double-checked and I don't think that I've cut the excerpts in a way that omits relevant context or misrepresents your statements. In any case all emails are preserved in full in the mailing list archives, allowing anyone to find a public record of what was actually said. Where I have noted factual errors, I have provided evidence (e.g. quotes from the RFC, or links to the mailing list archive) to back up my replies. I take pride in being thorough in my research and anything I state as a fact being correct. If I indeed made a factual mistake, I would appreciate it being pointed out. For the parts of my emails that state my *opinion* on something, others are free to disagree. This is why we are having a discussion - and ultimately a vote. While I certainly hope that my opinion matches that of the larger community, I don't take offense with anyone disagreeing. But I expect any factual statements to be correct and backed up by evidence as appropriate.
> Your current mail also seems to be largely a response to things I > didn't write, so I have no idea what you are trying to do here, other > than just sprouting rhetoric which everyone has heard before and nobody > is (currently) arguing about.
Except for one paragraph correcting a factual error (the presence or absence of a link in the RFC text), the email was solely explaining why I believe an (unconditional) “Impact Analysis” to be harmful. Given that you brought this up, I believe the email is very much in response to something that you wrote. I would also like to note that the mailing list is a public forum and the main authoritative source for decisions made by the PHP project. Emails - at least my emails - are primarily targeted at the PHP community at large and not to any specific participant in the discussion. If I feel that it is worth clarifying something, for example because it was a fairly recent change in policies that folks might have missed - such as deprecations officially not being considered a breaking change as of 6 months ago, then I will continue to do so.
> If the justification for a deprecation is strong enough, no impact > analysis will be able to stop the deprecation from happening. The only > thing the impact analysis can do in that case, is mentally prepare > people for the amount of work ahead and inform the decision whether the > eventual removal of the feature should be in PHP 9.0, or should be > delayed to PHP 10.0.
As I had mentioned in my reply to Rowan (https://news-web.php.net/php.internals/131528), I believe the actual deprecation period will be much more valuable in figuring out the impact.
> Being against adding an impact analysis for fear of this influencing > the vote, is kind of how Brexit happened, which really truly isn't the > "golden standard" you seem to think it is....
As I had mentioned the same reply, it is very easy to come up with any number one wants to by carefully selecting the method and data source for the impact analysis or just by accident (not taking account specific edge cases, of which PHP has many). As the saying goes “do not believe any statistic that you haven't forged yourself”. Best regards Tim Düsterhus

Unnamed Person

47 days ago
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

Kamil Tekiela

47 days ago
On Wed, 15 Jul 2026 at 23:45, Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl> wrote:
> > * The "Deprecate mysqli::stmt_init" deprecation does not mention the procedural `mysqli_stmt_init()` function, while I presume that will be deprecated too ?
Thanks for pointing that out. It's been a while since I wrote that proposal, but I checked it again, and you are right, I missed the procedural function. I have clarified it by adding a new paragraph and the deprecation message. I have also reworded the text without changing its meaning to highlight my impact analysis, which showed that this function is not used in any popular open-source project. FWIW, both of my proposals included impact analysis from the start. I was unable to find any usage of these functions in the wild. I hope this change is not going to reset the counter. This was a simple oversight when writing the text of the proposal.

Matteo Beccati

47 days ago
Hi, Il 16/07/2026 00:44, Juliette Reinders Folmer ha scritto:
> 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 Juliette, hat was extremely helpful! Surprisingly my legacy OSS project only had 3 warnings about list(). All the others had been most likely already converted a few years back and, despite also using gettext, it doesn't extensively use the _() function, like some other past projects. Cheers
-- Matteo Beccati

Tim Düsterhus

47 days ago
Hi On 2026-07-16 00:44, Juliette Reinders Folmer wrote:
> 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
This one is a little misleadingly formatted with the example projects being listed on the “in” line. Doctrine is only affected by “out”. This of course doesn't change anything, since it's a bundled proposal, but since you explicitly split the numbers per-keyword, I wanted to point it out.
> Deprecate _ as constant/compile time alias: 7 occurrences > Full details: > https://gist.github.com/jrfnl/f7ad1aad5842187e44c16be2f34ad9eb
For this one, I suspect you counted the one in ajthinking\archetype--v2.0.0\src\snippets\relationships.php, which is already deprecated as of PHP 8.4. You might've also counted the `use function foo as _;` ones, which should be grouped with the “Deprecate _ as function name” ones. The voting widget is a little unclear, but the deprecation message for that one clearly specifies class names only, so `use Foo as _;` So from what I understand the actual number would be 0 instead. Best regards Tim Düsterhus

Nick

47 days ago
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

Unnamed Person

47 days ago
On 16-7-2026 15:47, Nick Sdot wrote:
> > 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 >> >> >> 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). >
Thanks for doing that Nick! I'm sure people will find that helpful.

Tim Düsterhus

47 days ago
Hi On 2026-07-16 00:44, Juliette Reinders Folmer wrote:
> * While listed in the "introduction" section, there is no section for > the "Deprecate changing by-reference return modifier via inheritance" > deprecation.
Thanks, this proposal was initially part of the list and then removed by the author on July 9 based on the discussion in https://news-web.php.net/php.internals/131655. I've just removed the entry from the summary at the top. Best regards Tim Düsterhus

Rowan Tommins [IMSoP]

71 days ago
On 22 June 2026 14:13:19 BST, "Gina P. Banyard" <internals@gpb.moe> wrote:
>Hello internals, > >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
The one that stands out to me at first glance is the _() alias for gettext() I understand the motivation, but removing it is likely to be extremely disruptive, particularly paired with banning it as an identifier so users can't polyfill it. _() is basically the canonical way to use gettext in every language it's been ported to. The idea is that you can write code and templates with hard-coded English/base-language strings, and wrap them with a small amount of punctuation rather than extra words. While replacement would be relatively straightforward, affected codebases are likely to have thousands of uses, and the end result would be a reduction in readability. If we want to go down this route, we need a stronger justification than is given - does it actually cause a *problem* reserving it only in class-like context, or is the proposal just for neatness? Rowan Tommins [IMSoP]

Rowan Tommins [IMSoP]

71 days ago
On 22 June 2026 17:11:17 BST, "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk> wrote:
>The one that stands out to me at first glance is the _() alias for gettext() >
Sorry for the double reply, but I just checked the comments on the PR linked from the RFC https://github.com/php/php-src/pull/15360 There's a comment from Ilija saying that even the existing deprecation probably isn't needed, further weakening the case. There's another comment saying that class_alias already shows the deprecation, which 3v4l confirms: https://3v4l.org/QEcZs Rowan Tommins [IMSoP]

Bob Weinand

71 days ago
Hey Gina, Am 22.06.2026 um 15:13 schrieb Gina P. Banyard <internals@gpb.moe>: Hello internals, 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 As a reminder, this list has been compiled over the course of the past year by different people. And as usual, each deprecation will be voted in isolation. We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. Please note that with the new RFC policy rules the RFC must be finalized and in a "frozen" state by the 13th of July at the latest. Some deprecations should be non-controversial, others a bit more. If a deprecation is really controversial, it might warrant its own dedicated RFC or be dropped altogether. Best regards, Gina P. Banyard Thanks for compiling this list, I think it's more reasonable and a bit smaller than previous editions. Thanks for that. Could you please expand on the potential gains on "Deprecate ArrayIterator methods that inherit ArrayObject implementation"? A vague promise of unlocking potential optimizations is not very persuading. The "_" deprecation feels more like a change for the sake of it (consistency with a removal which has actual incoming functionality), even though there's no actual benefit for it for constants. There's no reason I can imagine why we'd ever need underscores in function call position for another language feature. I don't think we should deprecate "let". let is universally used for block-scoping in other languages. I don't think PHP should ever have block-scoping inside functions. The corresponding RFC was also declined with 50%+ of the vote. Hence I don't think we should deprecate a name which won't ever be needed. On "Deprecate changing by-reference return modifier via inheritance" - how exactly is this a LSP violation? If you assign a value without explicit "&" it'll be by-value, regardless of it being reference or not. If you put "&" there, you intentionally want a reference and you will get a warning when trying to use it. There's no magic "this value was a reference, hence this behaves differently now" in PHP, but references trivially decay to values, when used in a by-value context. This is basically covariance. There's no need to change this, and I assume there was a logic error from the author of that suggestion. One question, is "Passing objects which are interpreted as arrays" one big vote, or does each item get a vote? For array_walk(_recursive) specifically, I see some value of using it - sometimes data structures are available in object form, saving a cast ... and a cast back, which is not trivial, unless it's a stdclass. Everything else, I do agree with. Also, why would we deprecate CURLOPT_PROGRESSFUNCTION? According to https://grep.app/search?f.lang=PHP&q=CURLOPT_PROGRESSFUNCTION it's quite widely used in widely used libraries, like guzzle and symfony. And I wouldn't know what it's replacement would be? Bob

Rowan Tommins [IMSoP]

71 days ago
On 22 June 2026 17:38:29 BST, Bob Weinand <bobwei9@hotmail.com> wrote:
> >I don't think we should deprecate "let". let is universally used for block-scoping in other languages. I don't think PHP should ever have block-scoping inside functions. The corresponding RFC was also declined with 50%+ of the vote. Hence I don't think we should deprecate a name which won't ever be needed.
The RFC raised was for a unique-to-PHP concept of a special "scope block" using the "let" keyword in a way no other language does. Taking that vote to mean nobody wants block scoping is a huge stretch. In fact, I think block scoping would be a really useful addition to the language, and hope someone brings forward a proposal which more closely mirrors other Algol-descended languages. For me, it is a prerequisite for auto-capture closures, because it gives a way to unambiguously opt *out* of capture; but it also has plenty of other uses, just as it does in other languages. Whether we need to reserve the name to allow that, I will leave to those who know more about the parser. Rowan Tommins [IMSoP]

Theodore Brown

71 days ago
On Mon, June 22, 2026 at 10:38 Bob Weinand wrote:
> Also, why would we deprecate CURLOPT_PROGRESSFUNCTION? According to https://grep.app/search?f.lang=PHP&q=CURLOPT_PROGRESSFUNCTION it's quite widely used in widely used libraries, like guzzle and symfony. And I wouldn't know what it's replacement would be?
Per the PHP documentation for CURLOPT_PROGRESSFUNCTION [1]:
> deprecated as of cURL 7.32.0. Use CURLOPT_XFERINFOFUNCTION instead.
The cURL page for this option also states that it is deprecated since 7.32.0. [2] It probably would be good to update the RFC to clarify this. Sincerely, Theodore [1]: https://www.php.net/manual/en/curl.constants.php#constant.curlopt-progressfunction [2]: https://curl.se/libcurl/c/CURLOPT_PROGRESSFUNCTION.html

Ayesh - PHP.Watch

70 days ago
> Per the PHP documentation for CURLOPT_PROGRESSFUNCTION [1]: > > > deprecated as of cURL 7.32.0. Use CURLOPT_XFERINFOFUNCTION instead. > > The cURL page for this option also states that it is deprecated since 7.32.0. [2] > > It probably would be good to update the RFC to clarify this. > > Sincerely, > Theodore > > [1]: https://www.php.net/manual/en/curl.constants.php#constant.curlopt-progressfunction > [2]: https://curl.se/libcurl/c/CURLOPT_PROGRESSFUNCTION.html
Although libcurl documents `CURLOPT_PROGRESSFUNCTION` and `CURLOPT_XFERINFOFUNCTION` as separate options, they are effectively the same kind of API from PHP userland’s perspective: both register a progress callback and use the same return convention to abort a transfer. Because of that, ext/curl could internally map `CURLOPT_PROGRESSFUNCTION` to libcurl’s `CURLOPT_XFERINFOFUNCTION` instead of introducing a PHP deprecation for the legacy constant. The only `CURL*` PHP constant we deprecated in PHP was `CURLOPT_BINARYTRANSFER`[^1], which had very small usage then and was already a no-op option. In PHP 5.6, six constants[^4] were removed. Since this constant is used frequently, and we can rewrite it to use `XFERINFOFUNCTION`, we can simplify things for hundreds of library maintainers. This is especially true because `CURLOPT_PROGRESSFUNCTION` and `CURLOPT_XFERINFOFUNCTION` are practically identical within PHP. We already maintain BC for constants deprecated in libcurl, but still support them in PHP without any deprecation notices: - CURLINFO_HTTP_CODE[^2] (deprecated in libcurl 7.10.8) - CURLOPT_ENCODING[^3] (deprecated in libcurl 7.21.6) The only Curl constant I'd propose to deprecate would be CURLE_OBSOLETE[^5]. It is still declared in PHP but is no longer[^6] used in libcurl. [^1]: https://php.watch/codex/CURLOPT_BINARYTRANSFER [^2]: https://php.watch/codex/CURLINFO_HTTP_CODE [^3]: https://php.watch/codex/CURLOPT_ENCODING [^4]: https://php.watch/codex?search=CURL [^5]: https://php.watch/codex/CURLE_OBSOLETE [^6]: https://github.com/curl/curl/blob/master/include/curl/curl.h

Tim Düsterhus

70 days ago
Hi On 6/22/26 18:38, Bob Weinand wrote:
> Also, why would we deprecate CURLOPT_PROGRESSFUNCTION? According to https://grep.app/search?f.lang=PHP&q=CURLOPT_PROGRESSFUNCTION it's quite widely used in widely used libraries, like guzzle and symfony. And I wouldn't know what it's replacement would be?
This looks like an editorial error. The deprecation is only listed in the table of contents, but has no dedicated section. The TOC entry was added on January, 26th by devnexen: https://wiki.php.net/rfc/deprecations_php_8_6?do=diff&rev2%5B0%5D=1767204361&rev2%5B1%5D=1769465262&difftype=sidebyside Best regards Tim Düsterhus

Volker Dusch

62 days ago
On Mon, Jun 22, 2026 at 6:44 PM Bob Weinand <bobwei9@hotmail.com> wrote:
> On "Deprecate changing by-reference return modifier via inheritance" - how exactly is this a LSP violation? If you assign a value without explicit "&" it'll be by-value, regardless of it being reference or not. If you put "&" there, you intentionally want a reference and you will get a warning when trying to use it. There's no magic "this value was a reference, hence this behaves differently now" in PHP, but references trivially decay to values, when used in a by-value context. > This is basically covariance. There's no need to change this, and I assume there was a logic error from the author of that suggestion.
Hi Bob, Sorry for the late reply. Thank you for the correction. Would you suggest I remove that sentence from the proposal or that I retract the proposal?

Bob Weinand

62 days ago
Hey Volker,
> Am 01.07.2026 um 15:32 schrieb Volker Dusch <edorian@php.net>: > > On Mon, Jun 22, 2026 at 6:44 PM Bob Weinand <bobwei9@hotmail.com> wrote: > >> On "Deprecate changing by-reference return modifier via inheritance" - how exactly is this a LSP violation? If you assign a value without explicit "&" it'll be by-value, regardless of it being reference or not. If you put "&" there, you intentionally want a reference and you will get a warning when trying to use it. There's no magic "this value was a reference, hence this behaves differently now" in PHP, but references trivially decay to values, when used in a by-value context. >> This is basically covariance. There's no need to change this, and I assume there was a logic error from the author of that suggestion. > > Hi Bob, > > Sorry for the late reply. > > Thank you for the correction. Would you suggest I remove that sentence > from the proposal or that I retract the proposal?
Given that it seems the whole argument in favour of that deprecation is flawed, I would suggest a complete retraction. Thanks, Bob

Seifeddine Gmati

70 days ago
On Mon, Jun 22, 2026, 2:16 PM Gina P. Banyard <internals@gpb.moe> wrote:
> Hello internals, > > 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 > > As a reminder, this list has been compiled over the course of the past > year by different people. > > And as usual, each deprecation will be voted in isolation. > > We still have a bit of time anyone else to propose additional > deprecations, and if you have write access feel free to add them directly > to the RFC. > Please note that with the new RFC policy rules the RFC must be finalized > and in a "frozen" state by the 13th of July at the latest. > > Some deprecations should be non-controversial, others a bit more. > If a deprecation is really controversial, it might warrant its own > dedicated RFC or be dropped altogether. > > > Best regards, > > Gina P. Banyard >
Hi Gina, Thank you the RFC. Overall, everything looks good, however, i object (although not voting) to deprecating `in` and `out`, because their position in generics type parameter does not require them to be reserved keyword, and there's no parser ambiguity. `inout` on the other hand does make sense to deprecate for potential future inout parameters because there's an ambiguity with untyped parameters ( in `inout $x`, is it the type or modifier ). Cheers, Seifeddine.

Gina P. Banyard

70 days ago
On Monday, 22 June 2026 at 23:24, Seifeddine Gmati <azjezz@carthage.software> wrote: > Overall, everything looks good, however, i object (although not voting) to deprecating `in` and `out`, because their position in generics type parameter does not require them to be reserved keyword, and there's no parser ambiguity. `inout` on the other hand does make sense to deprecate for potential future inout parameters because there's an ambiguity with untyped parameters ( in `inout $x`, is it the type or modifier ). > >> If we provide a new set of by-reference parameters I think we would want to have the possibility to do: - inout for mutable references - in for immutable references - out for out parameters (such as the $matches parameter of preg_match()) where the input value is explicitly discarded Thus, I would prefer to reserve them in bulk and if it turns out we don't use them we can always remove the restriction. Best regards, Gina P. Banyard

Seifeddine Gmati

70 days ago
On Tue, 23 Jun 2026 at 11:50, Gina P. Banyard <internals@gpb.moe> wrote:
> > On Monday, 22 June 2026 at 23:24, Seifeddine Gmati <azjezz@carthage.software> wrote: > > Overall, everything looks good, however, i object (although not voting) to deprecating `in` and `out`, because their position in generics type parameter does not require them to be reserved keyword, and there's no parser ambiguity. `inout` on the other hand does make sense to deprecate for potential future inout parameters because there's an ambiguity with untyped parameters ( in `inout $x`, is it the type or modifier ). > > > If we provide a new set of by-reference parameters I think we would want to have the possibility to do: > > inout for mutable references > in for immutable references > out for out parameters (such as the $matches parameter of preg_match()) where the input value is explicitly discarded > > > Thus, I would prefer to reserve them in bulk and if it turns out we don't use them we can always remove the restriction. > > Best regards, > > Gina P. Banyard >
The idea is interesting, i would say it's fine to mark them as reserved then. I assumed the only reason for reserving them was generics. Cheers, Seifeddine.

Weedpacket

70 days ago
On 2026-06-23 01:13, Gina P. Banyard wrote:
> > We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. >
Is spl_object_hash() still useful? The string it creates used to be quite a bit more complex, but eventually it became equivalent to str_pad(dechex(spl_object_id($obj)), 16, '0', STR_PAD_LEFT) . '0000000000000000' I.e., it provides exactly the same content as spl_object_id, but in a much more obtuse way. For anyone _needing_ that format, the polyfill is just above. I suppose there might be changes in the future which will make the hash more useful (parallelism where objects are created simultaneously and independently), but then it would be spl_object_id() that has trouble coping.

youkidearitai

70 days ago
Hi, Gina and Internals I agree deprecate that "Passing object for $vars parameter of mb_convert_variables()". However, I have other opinion.(A little bit) mb_convert_variable and mb_convert_encoding parameter of $encoding is different behavior of `$encoding = "auto"`. If we will decide that mb_convert_variable is deprecate and delete, We need think that behavior. Anyway, This deprecate of PHP 8.6 is okay to me. Regards Yuya
-- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------

Gina P. Banyard

70 days ago
On Tuesday, 23 June 2026 at 00:49, Morgan <weedpacket@varteg.nz> wrote:
> On 2026-06-23 01:13, Gina P. Banyard wrote: > > > > We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. > > > Is spl_object_hash() still useful? The string it creates used to be > quite a bit more complex, but eventually it became equivalent to > > str_pad(dechex(spl_object_id($obj)), 16, '0', STR_PAD_LEFT) . > '0000000000000000' > > I.e., it provides exactly the same content as spl_object_id, but in a > much more obtuse way. For anyone _needing_ that format, the polyfill is > just above. > > > I suppose there might be changes in the future which will make the hash > more useful (parallelism where objects are created simultaneously and > independently), but then it would be spl_object_id() that has trouble > coping.
If you provide me with text proposal (ideally in DokuWiki format, but markdown is fine) I'm happy to include it in the bulk RFC. I will however not be writing it myself. Best regards, Gina P. Banyard

Sjoerd Langkemper

70 days ago
I would like to add the dechunk filter to the deprecation list, but there is some discussion around how to implement that since it is used internally by the HTTP fopen wrapper. More information here: https://github.com/php/php-src/issues/21983 https://github.com/php/php-src/pull/22036 https://github.com/php/php-src/pull/22396/changes Regards, Sjoerd Langkemper

Nicolas Grekas

70 days ago
Le mar. 23 juin 2026, 09:23, Sjoerd Langkemper <sjoerd-php@linuxonly.nl> a écrit :
> I would like to add the dechunk filter to the deprecation list, but there > is some discussion around how to implement that since it is used internally > by the HTTP fopen wrapper. > > More information here: > https://github.com/php/php-src/issues/21983 > https://github.com/php/php-src/pull/22036 > https://github.com/php/php-src/pull/22396/changes > > Regards, > > Sjoerd Langkemper >
Please don't, it's used in userland also. Cheers

Sjoerd Langkemper

70 days ago
On Tue, Jun 23, 2026, at 09:26, Nicolas Grekas wrote:
> Please don't, it's used in userland also.
Thanks, that is interesting. Do you have more information about this? Where and how is it used? Do you have an example? Regards, Sjoerd Langkemper

Nicolas Grekas

70 days ago
Le mar. 23 juin 2026, 09:43, Sjoerd Langkemper <sjoerd-php@linuxonly.nl> a écrit :
> On Tue, Jun 23, 2026, at 09:26, Nicolas Grekas wrote: > > Please don't, it's used in userland also. > > > Thanks, that is interesting. Do you have more information about this? > Where and how is it used? Do you have an example? > > Regards, > > Sjoerd Langkemper >
Sure, here is the pointer: https://github.com/symfony/symfony/blob/dce1b899ab0c0e4cef9159c083ef535387a8db12/src/Symfony/Component/HttpClient/Response/NativeResponse.php#L188

Arnaud.lb

67 days ago
On Tue, Jun 23, 2026 at 9:49 AM Nicolas Grekas <nicolas.grekas+php@gmail.com> wrote:
> > > Le mar. 23 juin 2026, 09:43, Sjoerd Langkemper <sjoerd-php@linuxonly.nl> > a écrit : > >> On Tue, Jun 23, 2026, at 09:26, Nicolas Grekas wrote: >> >> Please don't, it's used in userland also. >> >> >> Thanks, that is interesting. Do you have more information about this? >> Where and how is it used? Do you have an example? >> >> Regards, >> >> Sjoerd Langkemper >> > > Sure, here is the pointer: > > https://github.com/symfony/symfony/blob/dce1b899ab0c0e4cef9159c083ef535387a8db12/src/Symfony/Component/HttpClient/Response/NativeResponse.php#L188 >
Hi, Can we deprecate the filter only in php://filter URLs, and not in the function-based filter API? (like stream_filter_append) Legitimate cases use the function-based API, while adversarial ones use the URL-based API. Deprecating in the URL-based API only would address the issue without breaking legitimate code. Regards,

Sjoerd Langkemper

67 days ago
On Fri, Jun 26, 2026, at 14:42, Arnaud Le Blanc wrote:
> Can we deprecate the filter only in php://filter URLs, and not in the function-based filter API?
Yes. this would be a practical solution that prevents misuse of dechunk in attacks, while still providing it for legitimate use. It is technically possible, but it won't be a pretty implementation. It would basically be `if (name==dechunk) raise_error()` in the code that parses the filter URL. It would break the consistency of the filter API. Perhaps it would be useful to first deprecate and remove dechunk in php://filter URLs and later deprecate and remove it altogether, but doing only the first without doing the latter would be a real hack. An alternative could be to offer http_dechunk() as a function, instead of as a filter, to provide an easier upgrade path. A more rigorous approach could be to deprecate the whole of php://filter URLs. Regards, Sjoerd Langkemper

Jakub Zelenka

66 days ago
On Fri, Jun 26, 2026 at 5:38 PM Sjoerd Langkemper <sjoerd-php@linuxonly.nl> wrote:
> On Fri, Jun 26, 2026, at 14:42, Arnaud Le Blanc wrote: > > Can we deprecate the filter only in php://filter URLs, and not in the > function-based filter API? > > > Yes. this would be a practical solution that prevents misuse of dechunk in > attacks, while still providing it for legitimate use. It is technically > possible, but it won't be a pretty implementation. It would basically be > `if (name==dechunk) raise_error()` in the code that parses the filter URL. > It would break the consistency of the filter API. > >
Why can't you create a new version of php_stream_filter_create (e.g. php_stream_filter_create_ex) where you could pass some flags indicating if it comes from the url (php_stream_apply_filter_list)?Then filter itself could make such decision (it would probably require changing php_stream_filter_factory but that might be acceptable). Kind regards, Jakub

Sjoerd Langkemper

65 days ago
On Fri, Jun 26, 2026, at 23:41, Jakub Zelenka wrote:
> On Fri, Jun 26, 2026 at 5:38 PM Sjoerd Langkemper <sjoerd-php@linuxonly.nl> wrote:__ >> On Fri, Jun 26, 2026, at 14:42, Arnaud Le Blanc wrote: >>> Can we deprecate the [dechunk] filter only in php://filter URLs, and not in the function-based filter API? >> Yes. ..., but it won't be a pretty implementation. > Why can't you create a new version of php_stream_filter_create (e.g. php_stream_filter_create_ex) ...
Ok, that might work. If the implementation won't be a problem we should probably determine what we want from a functional perspective: deprecate dechunk only in php://filter URLs, or for every use? Perhaps we should just put it up to a vote in the RFC? I still think deprecating dechunk completely is a good option. It is not documented. Dechunk decoding is quite easy to implement in user-land PHP, there is no reason it should be provided by PHP itself. Regards, Sjoerd

Daniel Scherzer

69 days ago
On Tue, Jun 23, 2026 at 4:51 PM Gina P. Banyard <internals@gpb.moe> wrote:
> Hello internals, > > 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 > > As a reminder, this list has been compiled over the course of the past > year by different people. > > And as usual, each deprecation will be voted in isolation. > > We still have a bit of time anyone else to propose additional > deprecations, and if you have write access feel free to add them directly > to the RFC. > Please note that with the new RFC policy rules the RFC must be finalized > and in a "frozen" state by the 13th of July at the latest. > > Some deprecations should be non-controversial, others a bit more. > If a deprecation is really controversial, it might warrant its own > dedicated RFC or be dropped altogether. > > > Best regards, > > Gina P. Banyard >
Thanks for managing this - amazing how fast time flies. I've added a few new entries, including the spl_object_hash() deprecation suggested by Morgan. -Daniel

Weedpacket

69 days ago
On 2026-06-24 11:58, Daniel Scherzer wrote:
> > > I've added a few new entries, including the spl_object_hash() > deprecation suggested by Morgan. > > -Daniel
Oh, thank you for that; I was just about to write that up myself. Yup: pretty much every use I've seen of spl_object_hash (which I admit was only a small sample of lots of uses) is as an array key, where an integer would work just as well (and SplObjectStorage was a poor fit because it _wasn't an array_). For every other location I couldn't see what it achieved that a plain int couldn't and the places where its format as "32 hex digits" was relied on appeared to be because "that's the format spl_object_hash() outputs". The change from the more complex hash came in 8.1 without even a changelog entry. The only relevant discussion I could find was at https://github.com/php/php-src/pull/7010

Weedpacket

68 days ago
On 2026-06-23 01: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 >
Regarding deprecating non-canonical type names: It's a different category of problem (and a lot more difficult than just swapping out an alias), but gettype() returns "double" and "integer" for floats and ints (and "boolean" for bools). A change would require users to write a translator wrapper around gettype that continues to output the old names and call that until they're able to replace all their uses of them: $t = gettype($v); return $t === 'integer' ? 'int' : ($t === 'double' ? 'float' : $t);

Tim Düsterhus

68 days ago
Hi Am 2026-06-25 00:58, schrieb Morgan:
> It's a different category of problem (and a lot more difficult than > just swapping out an alias), but gettype() returns "double" and > "integer" for floats and ints (and "boolean" for bools). > > A change would require users to write a translator wrapper around > gettype that continues to output the old names and call that until > they're able to replace all their uses of them: > > $t = gettype($v); > return $t === 'integer' ? 'int' : ($t === 'double' ? 'float' : $t);
There already is `get_debug_type()` as a replacement that is documented to:
> [differ] from gettype() in that it returns type names that are more > consistent with actual usage, rather than those present for historical > reasons
And the documentation page for `gettype()` also mentions that:
> For type checking, use is_* functions.
meaning that `gettype()` is not supposed to be used for actual type *checking* (e.g. with a `switch(gettype($var))`). If it's not intended for this use, then “human readable output” remains as a possible use case, which is already better solved by `get_debug_type()` which outputs the canonical names and also class names instead of just `object`. Given the replacement already being available since PHP 8.0 (and polyfillable, see https://github.com/symfony/polyfill/blob/a9a8687879dfea232e90d38ba949f65c3ece4456/src/Php80/Php80.php#L28-L58), the correct action would be not to adjust the function any more and to deprecate it with a reference to `get_debug_type()`. Best regards Tim Düsterhus

Derick Rethans

64 days ago
On Mon, 22 Jun 2026, Gina P. Banyard wrote:
> Hello internals, > > 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
I think I am not in favour of the following: - Deprecate returning from a finally block If somebody uses a `return` in a `finally` block, than this could just as well be intentional. - Deprecate the _() function alias for gettext() AFAIK, this is heavily used as it was (is) the original (C) way of using it. I don't see an impact analysis for this one, and unless it's having *no* impact, I don't think we should remove it. - Deprecate Metaphone Function I don't see why this is useful. It causes no harm AFAICT. - Deprecate dechunk filter I believe that if you deprecate this as a filter, then there should be a userland function that does the same thing (in a sane way). cheers, Derick
-- https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social

Osama Aldemeery

64 days ago
On Mon, Jun 29, 2026 at 1:56 PM Derick Rethans <derick@php.net> wrote:
> I think I am not in favour of the following: > > - Deprecate returning from a finally block > > If somebody uses a `return` in a `finally` block, than this could just > as well be intentional. >
Hi Derick, Yes, as you have probably already seen in the RFC, 9 out of the 12 instances across the top ~5000 packages were intentional, but the proposal is not really aimed at intent. Deprecating it takes no capability away from anyone doing this on purpose, since the same result can still be expressed in other ways, sometimes by just moving the `return` out of the `finally`, but at the same time it protects the people who do not pay attention to it (which could even be some of those deliberately using it today, once they add a `return` or a `throw` in the `try` later and its result silently disappears). I also want to bring up again that even though I am suggesting a deprecation, I am still genuinely interested to know whether someone feels a warning, or even a notice, would fit better, so that if the deprecation gets voted down we would at least have an impression of where people stand. The main point here is that *silently* discarding the in-flight state, without giving a single hint about it, is a footgun, and that silent part is really the concern here. A `return` in `finally` quietly discarding an in-flight return value, and more importantly an in-flight exception, so a thrown error can just disappear with nothing reported anywhere. Regards, Osama

Seifeddine Gmati

64 days ago
Hello Internals, I have updated the RFC to include a deprecation proposal for the `list()` construct. ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct Cheers, Seifeddine.

Rowan Tommins [IMSoP]

64 days ago
On 29/06/2026 17:37, Seifeddine Gmati wrote:
> Hello Internals, > > I have updated the RFC to include a deprecation proposal for the > `list()` construct. > > ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct
I don't think it makes sense to deprecate list() if we're not deprecating array() - they're exact counterparts, and both replaced by the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4, but as a replacement for list() was only added in PHP 7.1. I agree that it's not immediately clear that array() constructs and list() extracts, but I think your example is unfair, because both array($a, $b) and list("a" => $a, "b" => $b) are also valid. A possible justification would be that one is more common than the other, but right now there's no discussion or analysis of that. (Which as I've said elsewhere in this thread will be an automatic "No" vote from me if it's still the case at voting time.)
-- Rowan Tommins [IMSoP]

Seifeddine Gmati

64 days ago
On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:
> > On 29/06/2026 17:37, Seifeddine Gmati wrote: > > Hello Internals, > > > > I have updated the RFC to include a deprecation proposal for the > > `list()` construct. > > > > ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct > > > I don't think it makes sense to deprecate list() if we're not > deprecating array() - they're exact counterparts, and both replaced by > the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4, > but as a replacement for list() was only added in PHP 7.1.
I'm actually in favor of deprecating `array()` too, and I raised this on the #php-internals Discord channel. The motivation there is weaker though: unlike `list`, deprecating `array()` does not free up a keyword, since `array` remains a type. The grammar simplification and having fewer things for newcomers to learn still apply, and IMO are good reasons on their own. If there's appetite for it, I'm happy to add it to the RFC.
> I agree that it's not immediately clear that array() constructs and > list() extracts, but I think your example is unfair, because both > array($a, $b) and list("a" => $a, "b" => $b) are also valid.
The example isn't claiming the two forms can't be written the other way around. The point is purely about how they read: set next to `array("a" => $a, "b" => $b)`, the construct `list($a, $b)` looks like it builds some kind of list value, a sibling of `array()`, when in fact it constructs nothing and instead pulls values out of an existing array. And `list("a" => $a, "b" => $b)` actually reinforces the case. In PHP you can't tell a construct from a function call just by looking at it, so someone reading that for the first time has no way to understand why a "funtcion" called `list` is being called in a write context with key/value pairs. The name actively misleads.
> A possible justification would be that one is more common than the > other, but right now there's no discussion or analysis of that. (Which > as I've said elsewhere in this thread will be an automatic "No" vote > from me if it's still the case at voting time.)
I don't think relative frequency is the core justification here, so I'd rather not anchor the RFC on usage numbers. The case rests on the keyword being freed for a potential future `list` type, grammar simplification, and the readability point above, regardless of which form is more common. Cheers, Seifeddine.

Tim Düsterhus

62 days ago
Hi Am 2026-06-29 20:37, schrieb Seifeddine Gmati:
> I'm actually in favor of deprecating `array()` too, and I raised this > on the #php-internals Discord channel. The motivation there is weaker > though: unlike `list`, deprecating `array()` does not free up a > keyword, since `array` remains a type. The grammar simplification and > having fewer things for newcomers to learn still apply, and IMO are > good reasons on their own. If there's appetite for it, I'm happy to > add it to the RFC.
FWIW: I still have a rough draft to make `array()` (or rather: all non-object types) proper functions that effectively would “stand in” as cast operators. For `array()` specifically this would allow a named-argument style of defining arrays with “unquoted keys”: `array(foo: 1, bar: 2)`. Best regards Tim Düsterhus

Seifeddine Gmati

61 days ago
On Wed, 1 Jul 2026 at 18:31, Tim Düsterhus <tim@bastelstu.be> wrote:
> > Hi > > Am 2026-06-29 20:37, schrieb Seifeddine Gmati: > > I'm actually in favor of deprecating `array()` too, and I raised this > > on the #php-internals Discord channel. The motivation there is weaker > > though: unlike `list`, deprecating `array()` does not free up a > > keyword, since `array` remains a type. The grammar simplification and > > having fewer things for newcomers to learn still apply, and IMO are > > good reasons on their own. If there's appetite for it, I'm happy to > > add it to the RFC. >
Hi Tim,
> FWIW: I still have a rough draft to make `array()` (or rather: all > non-object types) proper functions that effectively would “stand in” as > cast operators. For `array()` specifically this would allow a > named-argument style of defining arrays with “unquoted keys”: > `array(foo: 1, bar: 2)`.
This would require deprecating `array()` first anyway, no? Otherwise, dealing with it during parsing would be hacky (looking ahead at `array(foo` for `:` or `=>` or `,` or `)` to decide if it's an array or a function call, possible, but hacky think ).

Tim Düsterhus

61 days ago
Hi Am 2026-07-01 21:25, schrieb Seifeddine Gmati:
>> FWIW: I still have a rough draft to make `array()` (or rather: all >> non-object types) proper functions that effectively would “stand in” >> as >> cast operators. For `array()` specifically this would allow a >> named-argument style of defining arrays with “unquoted keys”: >> `array(foo: 1, bar: 2)`. > > This would require deprecating `array()` first anyway, no? Otherwise, > dealing with it during parsing would be hacky (looking ahead at > `array(foo` for `:` or `=>` or `,` or `)` to decide if it's an array > or a function call, possible, but hacky think ).
It's not particularly pretty, but possible. The `array()` syntax will not actually be a function call, it will just look like one. Basically the `:` syntax can just parse into the same AST as the `=>` syntax, the grammar just needs to make sure that they may not be mixed. The array() function will be made available in addition to support `\array` (i.e. with a fully-qualified name) and `array(...)` (i.e. a first class callable). My rough draft is in https://github.com/php/php-src/pull/18613, I think there are some issues still with properly compiling the array, because the AST node for `=>` takes the two sides in different order compared to named arguments and I wanted to document the AST structure first (and then got distracted by more important things). Best regards Tim Düsterhus

Michael Morris

62 days ago
On Mon, Jun 29, 2026 at 2:38 PM Seifeddine Gmati <azjezz@carthage.software> wrote:
> On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP] > <imsop.php@rwec.co.uk> wrote: > > > > On 29/06/2026 17:37, Seifeddine Gmati wrote: > > > Hello Internals, > > > > > > I have updated the RFC to include a deprecation proposal for the > > > `list()` construct. > > > > > > ref: > https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct > > > > > > I don't think it makes sense to deprecate list() if we're not > > deprecating array() - they're exact counterparts, and both replaced by > > the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4, > > but as a replacement for list() was only added in PHP 7.1. > > I'm actually in favor of deprecating `array()` too, and I raised this > on the #php-internals Discord channel.
Are you crazy? That would invalidate at least three quarters of the WordPress core code base and almost all of it's plugins, not to mention THOUSANDS of tutorials on stack overflow. And whether you like it or not about 40-60% of PHP sites use WordPress, depending on who you ask. That would almost certainly cause that community to either refuse to upgrade, leading to the problem the Python community faced with 2 & 3, or cause them to fork PHP. To be clear, I find it ugly as Hell too, and I'd love to see the end of the @ error suppression operator, but there are things that simply cannot be done.

Kamil Tekiela

61 days ago
On Wed 1 Jul 2026, 20:35 Michael Morris, <tendoaki@gmail.com> wrote:
> > > On Mon, Jun 29, 2026 at 2:38 PM Seifeddine Gmati <azjezz@carthage.software> > wrote: > >> On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP] >> <imsop.php@rwec.co.uk> wrote: >> > >> > On 29/06/2026 17:37, Seifeddine Gmati wrote: >> > > Hello Internals, >> > > >> > > I have updated the RFC to include a deprecation proposal for the >> > > `list()` construct. >> > > >> > > ref: >> https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct >> > >> > >> > I don't think it makes sense to deprecate list() if we're not >> > deprecating array() - they're exact counterparts, and both replaced by >> > the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4, >> > but as a replacement for list() was only added in PHP 7.1. >> >> I'm actually in favor of deprecating `array()` too, and I raised this >> on the #php-internals Discord channel. > > > Are you crazy? That would invalidate at least three quarters of the > WordPress core code base and almost all of it's plugins, not to mention > THOUSANDS of tutorials on stack overflow. And whether you like it or not > about 40-60% of PHP sites use WordPress, depending on who you ask. > > That would almost certainly cause that community to either refuse to > upgrade, leading to the problem the Python community faced with 2 & 3, or > cause them to fork PHP. > > To be clear, I find it ugly as Hell too, and I'd love to see the end of > the @ error suppression operator, but there are things that simply cannot > be done. >
That's a very strong stance. It would invalidate a lot of old code but it's a very simple change that can be done automatically. Most of the up-to-date code already switched to the new syntax so there is a trend in community's code towards the new style. Deprecating array() would only speed it up. We're not talking here about deprecating arrays, just the old array() construct. Deprecating list() is a little more challenging as not enough time has passed for old codebases to migrate to the new syntax but it also wouldn't be world shattering as the change is very simple. The benefit of this would be that we would be modernizing the language and removing two ways of doing the identical thing, which would be a very good thing for new users. No more confusion and messy code. Compared to the error suppression operator or pass-by-ref, this is a very simple and unproblematic deprecation. We might want to delay the removal until PHP 10 but I see no reason to hold back on deprecation.

Seifeddine Gmati

61 days ago
On Wed, 1 Jul 2026 at 19:36, Michael Morris <tendoaki@gmail.com> wrote:
> > > > On Mon, Jun 29, 2026 at 2:38 PM Seifeddine Gmati <azjezz@carthage.software> wrote: >> >> On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP] >> <imsop.php@rwec.co.uk> wrote: >> > >> > On 29/06/2026 17:37, Seifeddine Gmati wrote: >> > > Hello Internals, >> > > >> > > I have updated the RFC to include a deprecation proposal for the >> > > `list()` construct. >> > > >> > > ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct >> > >> > >> > I don't think it makes sense to deprecate list() if we're not >> > deprecating array() - they're exact counterparts, and both replaced by >> > the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4, >> > but as a replacement for list() was only added in PHP 7.1. >> >> I'm actually in favor of deprecating `array()` too, and I raised this >> on the #php-internals Discord channel. > >
Hi Michael,
> Are you crazy?
Yes.
> That would invalidate at least three quarters of the WordPress core code base and almost all of it's plugins, not to mention THOUSANDS of tutorials on stack overflow. And whether you like it or not about 40-60% of PHP sites use WordPress, depending on who you ask.
The migration is running a single command: `ast-grep -p 'array($$$ARGS)' -r '[$$$ARGS]' --lang php -U` I dislike the idea that the langauge should not progress because people genuinely don't want to take 2 minutes to upgrade their codebase. I don't think the WordPress team would have trouble replacing `array()` with `[]` given that the minimum requirement for WordPress is PHP 8.3. Older WordPress installations don't have to upgrade because if they didn't bother upgrading WordPress, i doubt they will bother upgrading PHP :)
> That would almost certainly cause that community to either refuse to upgrade, leading to the problem the Python community faced with 2 & 3, or cause them to fork PHP.
I don't think a single syntax change like `array($x)` to `[$x]` would cause the Python 2 to Python 3 chaos here, given that the "modern" syntax already works in older PHP versions. Cheers, Seifeddine.

Unnamed Person

61 days ago
On 1-7-2026 21:18, Seifeddine Gmati wrote:
> On Wed, 1 Jul 2026 at 19:36, Michael Morris <tendoaki@gmail.com> wrote: >> On Mon, Jun 29, 2026 at 2:38 PM Seifeddine Gmati <azjezz@carthage.software> wrote: >>> On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP] >>> <imsop.php@rwec.co.uk> wrote: >>>> On 29/06/2026 17:37, Seifeddine Gmati wrote: >>>>> Hello Internals, >>>>> >>>>> I have updated the RFC to include a deprecation proposal for the >>>>> `list()` construct. >>>>> >>>>> ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct >>>> I don't think it makes sense to deprecate list() if we're not >>>> deprecating array() - they're exact counterparts, and both replaced by >>>> the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4, >>>> but as a replacement for list() was only added in PHP 7.1. >>> I'm actually in favor of deprecating `array()` too, and I raised this >>> on the #php-internals Discord channel. >> >
Hi all,
>> That would invalidate at least three quarters of the WordPress core code base and almost all of it's plugins, not to mention THOUSANDS of tutorials on stack overflow. And whether you like it or not about 40-60% of PHP sites use WordPress, depending on who you ask. > The migration is running a single command: `ast-grep -p > 'array($$$ARGS)' -r '[$$$ARGS]' --lang php -U` > > I don't think the WordPress team would have trouble replacing > `array()` with `[]` given that the minimum requirement for WordPress > is PHP 8.3. Older WordPress installations don't have to upgrade > because if they didn't bother upgrading WordPress, i doubt they will > bother upgrading PHP :)
Sorry to butt in, but a) the minimum PHP for WP is PHP 7.4 at the moment and b) the arguments for WordPress to stick with the old `array()` and `list()` has nothing to do with them "not bothering to upgrade". They are fully aware of the ease of upgrading and the (PHPCS) tooling to do so is available and has been for the longest time. Reasons for WordPress to **not** switch to short array/list syntax are far more along the lines of: * Code accessibility - it is much quicker to determine whether something is a list or an array when visually scanning code when the keywords are being used. * Searchability of the code base - searching for `array(` or `list(` will yield useful results, searching for `[` will yield a hundred times more results, most of which are not what one is looking for (array access, assignments etc). Other than that, they've brought up practical reasons for not switching to the new syntax in the past. Think along the lines of there being thousands of (often long-standing) open patches, which would need to be updated before they can be merged. The extra burden this would put on the limited amount of committers is another reason. So, please, if you use WP in this discussion to argue either side, please inform yourself before doing so. Personally, I believe both the code accessibility as well as the searchability arguments do have some value, so it might be a good idea for the discussion to focus more on those. Smile, Juliette

Michael Morris

61 days ago
On Wed, Jul 1, 2026 at 4:52 PM Juliette Reinders Folmer < php-internals_nospam@adviesenzo.nl> wrote:
> On 1-7-2026 21:18, Seifeddine Gmati wrote: > > On Wed, 1 Jul 2026 at 19:36, Michael Morris <tendoaki@gmail.com> <tendoaki@gmail.com> wrote: > > On Mon, Jun 29, 2026 at 2:38 PM Seifeddine Gmati <azjezz@carthage.software> <azjezz@carthage.software> wrote: > > On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP]<imsop.php@rwec.co.uk> <imsop.php@rwec.co.uk> wrote: > > On 29/06/2026 17:37, Seifeddine Gmati wrote: > > Hello Internals, > > I have updated the RFC to include a deprecation proposal for the > `list()` construct. > > ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct > > I don't think it makes sense to deprecate list() if we're not > deprecating array() - they're exact counterparts, and both replaced by > the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4, > but as a replacement for list() was only added in PHP 7.1. > > I'm actually in favor of deprecating `array()` too, and I raised this > on the #php-internals Discord channel. > > > > Hi all, > > That would invalidate at least three quarters of the WordPress core code base and almost all of it's plugins, not to mention THOUSANDS of tutorials on stack overflow. And whether you like it or not about 40-60% of PHP sites use WordPress, depending on who you ask. > > The migration is running a single command: `ast-grep -p > 'array($$$ARGS)' -r '[$$$ARGS]' --lang php -U` > > I don't think the WordPress team would have trouble replacing > `array()` with `[]` given that the minimum requirement for WordPress > is PHP 8.3. Older WordPress installations don't have to upgrade > because if they didn't bother upgrading WordPress, i doubt they will > bother upgrading PHP :) > > > Sorry to butt in, but a) the minimum PHP for WP is PHP 7.4 at the moment > and b) the arguments for WordPress to stick with the old `array()` and > `list()` has nothing to do with them "not bothering to upgrade". They are > fully aware of the ease of upgrading and the (PHPCS) tooling to do so is > available and has been for the longest time. > > Reasons for WordPress to **not** switch to short array/list syntax are far > more along the lines of: > * Code accessibility - it is much quicker to determine whether something > is a list or an array when visually scanning code when the keywords are > being used. > * Searchability of the code base - searching for `array(` or `list(` will > yield useful results, searching for `[` will yield a hundred times more > results, most of which are not what one is looking for (array access, > assignments etc). > > Other than that, they've brought up practical reasons for not switching to > the new syntax in the past. Think along the lines of there being thousands > of (often long-standing) open patches, which would need to be updated > before they can be merged. The extra burden this would put on the limited > amount of committers is another reason. > > So, please, if you use WP in this discussion to argue either side, please > inform yourself before doing so. > > Personally, I believe both the code accessibility as well as the > searchability arguments do have some value, so it might be a good idea for > the discussion to focus more on those. > > Smile, > Juliette > >
I didn't delve into the reasons WordPress is that way because I don't know them. I assumed they had them - no project that size that has ran that long does anything without much deliberation. It's not just the core team that has to change, it's all the plugins. Most sites have considerable custom theme code - the one I'm responsible for does. I don't use array() but there are corners I haven't touched yet that might because I inherited it. I could run that query, but I wouldn't be comfortable doing it because there are no tests for that old code. I do have tests, but most all of them step over the PHP backend and focus on the output of the twig templates because that's easier to test in the first place. I do have a sanity test that iterates over 150 pages of the site looking for PHP and JavaScript errors in the output or console, but that's a bare minimum. A lot of WordPress sites are ran by small outfits with no coder on staff at all and they delegate the server operation to a provider. Those providers often have hundreds, some thousands of sites. They don't have the staff to update every bloody one of them. This can be done. I strongly, strongly advise caution on it. Honestly, this is what I mean by saying perhaps it's time to have a strict mode language that is code first instead of template first among other features that would be nice to do but have severe BC implications.

Seifeddine Gmati

61 days ago
> It's not just the core team that has to change, it's all the plugins. Most sites have considerable custom theme code - the one I'm responsible for does.
Plugins can also upgrade just as easily, because the alternative already works for all supported PHP versions.
> I could run that query, but I wouldn't be comfortable doing it because there are no tests for that old code. I do have tests, but most all of them step over the PHP backend and focus on the output of the twig templates because that's easier to test in the first place. I do have a sanity test that iterates over 150 pages of the site looking for PHP and JavaScript errors in the output or console, but that's a bare minimum.
This part I can reassure you on directly: you don't need tests to make this specific change safely. `array($a, $b)`, `list($a, $b)`, and `[$a, $b]` compile to byte-identical opcodes. it's a guaranteed language equivalence, not a behavioural one that could differ at runtime, see https://3v4l.org/rlQa6/vld#v So a mechanical `array()` -> `[]` rewrite can't change what your code does, tests or no tests. That's a very different risk profile from a normal untested refactor.
> A lot of WordPress sites are ran by small outfits with no coder on staff at all and they delegate the server operation to a provider.
I don't think this is a language-design concern. A deprecation doesn't break anything on upgrade day; it emits a notice, and removal is a full major version away. An unmaintained site isn't chasing new PHP majors in the first place, so the scenario where it lands on a version that has *removed* `list()`/`array()` without anyone touching the code essentially doesn't arise on its own. And where it does arise, it's because a managed provider moved the PHP version under software that doesn't support it. Verifying that the code runs on the target version is the provider's responsibility. That's true for every deprecation and removal PHP has ever shipped, and it isn't a reason to hold the language's grammar fixed.

Michael Morris

61 days ago
On Wed, Jul 1, 2026 at 5:53 PM Seifeddine Gmati <azjezz@carthage.software> wrote:
> > It's not just the core team that has to change, it's all the plugins. > Most sites have considerable custom theme code - the one I'm responsible > for does. > > Plugins can also upgrade just as easily, because the alternative > already works for all supported PHP versions. > > > I could run that query, but I wouldn't be comfortable doing it because > there are no tests for that old code. I do have tests, but most all of them > step over the PHP backend and focus on the output of the twig templates > because that's easier to test in the first place. I do have a sanity test > that iterates over 150 pages of the site looking for PHP and JavaScript > errors in the output or console, but that's a bare minimum. > > This part I can reassure you on directly: you don't need tests to make > this specific change safely.
I'm stopping right there. I've watched people make proclamations like that, execute the code, crash servers costing thousands of dollars in downtime and promptly get fired. You've never been in a position of authority to make a pragmatic decision. No one with that burden would type what you've typed. Pragmatic decisions often suck, but they are made for sound reasons. Step out of your ivory tower sometime and maybe you'll learn that. I've stated my reasoning. I don't need to repeat it to deaf ears.

Seifeddine Gmati

61 days ago
> Sorry to butt in, but a) the minimum PHP for WP is PHP 7.4
I got the 8.3 number from their official website: https://wordpress.org/about/requirements/ , even if the requirement is 7.1, the `[]` syntax works fine there. So, this is not a problem.
> * Code accessibility - it is much quicker to determine whether something is a list or an array when visually scanning code when the keywords are being used.
`list(` does not mean a "list", PHP has no such type right now. It means you are destructuring an array, `list("foo" => $bar)` is valid. so "quicker to determine" is false, you can swap every `list(` usage with `array(` and the behavior will be exactly the same.
> * Searchability of the code base - searching for `array(` or `list(` will yield useful results, searching for `[` will yield a hundred times more results, most of which are not what one is looking for (array access, assignments etc).
Yes, it would also yield `$typed->array(`, `$posts->list(`, and more. If you are looking for a specific syntax, you should use AST based search tools, not grep text. In which case, you can easily grep for array construction using `[]` over writes/reads using array-access syntax. This has never been a problem in every other language that uses `[]` syntax.
> Other than that, they've brought up practical reasons for not switching to the new syntax in the past. Think along the lines of there being thousands of (often long-standing) open patches, which would need to be updated before they can be merged. The extra burden this would put on the limited amount of committers is another reason.
Again, i don't think the language should be held down because of a single project when the migration path is available, and works for all supported versions of that project, whether it's WordPress or any other. Cheers, Seifeddine.

Unnamed Person

61 days ago
On 1-7-2026 23:35, Seifeddine Gmati wrote:
>> Sorry to butt in, but a) the minimum PHP for WP is PHP 7.4 > I got the 8.3 number from their official website: > https://wordpress.org/about/requirements/ , even if the requirement is > 7.1, the `[]` syntax works fine there. So, this is not a problem.
Please look again on the same page. The _recommended_ version may be PHP 8.3, the minimum version ("Running on legacy versions?") is PHP 7.4 and only since recently.
>> * Code accessibility - it is much quicker to determine whether something is a list or an array when visually scanning code when the keywords are being used. > `list(` does not mean a "list", PHP has no such type right now. It > means you are destructuring an array, `list("foo" => $bar)` is valid. > so "quicker to determine" is false, you can swap every `list(` usage > with `array(` and the behavior will be exactly the same.
That's just plain untrue. The one is used for creating an array, the other for destructuring an array. Swapping `list(` usages with `array(` will in most cases result in a parse error. Example: https://3v4l.org/O7O4q#veol
> >> * Searchability of the code base - searching for `array(` or `list(` will yield useful results, searching for `[` will yield a hundred times more results, most of which are not what one is looking for (array access, assignments etc). > Yes, it would also yield `$typed->array(`, `$posts->list(`, and more. > If you are looking for a specific syntax, you should use AST based > search tools, not grep text. In which case, you can easily grep for > array construction using `[]` over writes/reads using array-access > syntax. This has never been a problem in every other language that > uses `[]` syntax.
Agreed, but that doesn't take anything away from the fact that WP uses it as an argument against switching to the short syntax. Smile, Juliette

Seifeddine Gmati

61 days ago
> Please look again on the same page. The _recommended_ version may be PHP 8.3, the minimum version ("Running on legacy versions?") is PHP 7.4 and only since recently.
8.3 is listed as the version up top, and 7.4 appears under "Running on legacy versions?", which the page itself flags as EOL and recommends upgrading away from. I'm not sure an End-Of-Life floor is the number we should be designing around, but it doesn't matter either way: `[]` destructuring has worked since PHP 7.1, so it's supported on every version WP runs on, 7.4 and 8.3 alike. The short syntax isn't version-gated for them under any reading of that page.
> That's just plain untrue. The one is used for creating an array, the other for destructuring an array.
You're correct, and I mistyped there. But that's a rewrite detail, not the point I was making. My point was about the *name*. The accessibility argument was that the keyword lets you tell "a list or an array" apart at a glance, and that's what i disagree on, because PHP has no list. `list()` doesn't construct anything; it destructures an array. The keyword names a type that doesn't exist, and it accepts keys (`list("foo" => $bar) = $arr`), which a genuine "list" wouldn't. So "the keyword tells you what it is" is exactly backwards here: the keyword tells you something false.
> Agreed, but that doesn't take anything away from the fact that WP uses it as an argument against switching to the short syntax.
I haven't seen anyone from the WP team make that argument in this thread, so I'd be cautious about treating it as WP's settled position rather than a reason attributed to them. And more importantly: even if it is their position, a single project's style preference shouldn't steer language design. Coding styles adapt to what the language offers *at the version they target*; that's the normal direction of the relationship. A project choosing to keep `array()`/`list()` in their own codebase is entirely their call, and deprecating the long forms doesn't force them to restyle historical code on any particular timeline. But "we'd rather keep writing it the old way" isn't a reason for the language to carry a redundant construct indefinitely.

Ayesh - PHP.Watch

64 days ago
> I have updated the RFC to include a deprecation proposal for the > `list()` construct. > > ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct >
Hi Seifeddine, I understand the reasoning behind freeing up the `list` keyword and having a canonical way to destructure an array. However, I would argue that the scale of this BC break far outweighs the benefits. A quick GitHub code search shows 7 million[^1] hits for "list(" in PHP files. If we deprecate and eventually drop `list()` in PHP 9, we can safely assume that a large portion of existing code will fail to compile in PHP 9. Furthermore, the documentation for `list()` offers no hint that `[]` is preferred over `list()`, and I would also argue that there is no reason to prefer one over the other. Code-style guides can dictate a project's or library's conventions, but we should take a more conservative approach if we really have a strong technical reason to prefer one syntax over another. Based on the RFC text, aside from freeing up the `list` keyword for potential future use, I do not see a sufficiently strong technical reason to deprecate `list()`. Thank you. [^1]: https://github.com/search?q=%22list%28%22+language%3APHP+&type=code

Seifeddine Gmati

64 days ago
On Mon, 29 Jun 2026 at 18:51, Ayesh Karunaratne <ayesh@php.watch> wrote:
> > > I have updated the RFC to include a deprecation proposal for the > > `list()` construct. > > > > ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct > > > > Hi Seifeddine, > I understand the reasoning behind freeing up the `list` keyword and > having a canonical way to destructure an array. However, I would argue > that the scale of this BC break far outweighs the benefits. > > A quick GitHub code search shows 7 million[^1] hits for "list(" in PHP > files.
That 7 million figure is misleading, as it also matches methods and functions with a `list` suffix. Excluding forks, archived, generated, and vendored code, and searching only for ` list($` brings it down to roughly 1 million: https://github.com/search?q=%22+list%28%24%22+lang%3Aphp+NOT+is%3Afork+NOT+is%3Aarchived+NOT+is%3Agenerated+NOT+is%3Avendored&type=code
> [...] If we deprecate and eventually drop `list()` in PHP 9, we can > safely assume that a large portion of existing code will fail to > compile in PHP 9.
That's the purpose of the deprecation period: like any feature or syntax that gets removed, it gives people time to migrate away from the old construct. In this case the migration is purely mechanical, and the RFC already provides a one-liner for it: `ast-grep run --pattern 'list($$$ARGS)' --rewrite '[$$$ARGS]' --lang php -U`
> Furthermore, the documentation for `list()` offers no hint that `[]` > is preferred over `list()`, and I would also argue that there is no > reason to prefer one over the other. Code-style guides can dictate a > project's or library's conventions, but we should take a more > conservative approach if we really have a strong technical reason to > prefer one syntax over another.
`list()` does not currently recommend `[]` because it has not yet been deprecated, and it exists only as an alternative syntax for `[]` in write positions ( post 7.1 ). Once deprecated, the documentation and coding styles will have to adopt the change. A library's stylistic preference for a redundant syntax should not dictate language design; it should follow the change.
> Based on the RFC text, aside from freeing up the `list` keyword for > potential future use, I do not see a sufficiently strong technical > reason to deprecate `list()`.
Freeing up the `list` keyword for a potential future `list` type is indeed the main motivation, but not the only one: it also simplifies the language grammar and leaves newcomers with fewer things to learn. Cheers, Seifeddine.

Weedpacket

63 days ago
On 2026-06-30 06:29, Seifeddine Gmati wrote:
> > That 7 million figure is misleading, as it also matches methods and > functions with a `list` suffix. Excluding forks, archived, generated, > and vendored code, and searching only for ` list($` brings it down to > roughly 1 million: > https://github.com/search?q=%22+list%28%24%22+lang%3Aphp+NOT+is%3Afork+NOT+is%3Aarchived+NOT+is%3Agenerated+NOT+is%3Avendored&type=code >
You can bring it back up to ~2.4 million with a regular expression: https://github.com/search?q=%2F%5Cblist%5Cs*%5C%28%2F+lang%3Aphp+NOT+is%3Afork+NOT+is%3Aarchived+NOT+is%3Agenerated+NOT+is%3Avendored&type=code

Nick

61 days ago
On 30.06.26 00:37, Seifeddine Gmati wrote:
> Hello Internals, > > I have updated the RFC to include a deprecation proposal for the > `list()` construct. > > ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct > > Cheers, > Seifeddine.
Hey Seifeddine with you here on the problems with list(); that it should be deprecated and go eventually. Though, you get quite some resistance with strong arguments. You said in one of your answers something like "one project holding back the PHP language". While in essence true, Wordpress is not just any project -- it's still the biggest multiplicator for PHP usage. The amount of deprecation logs printed on a daily basis, the amount of support generated, and the general impact will be huge. I know that's not what you signed up for when adding this deprecation to the RFC, but perhaps getting `list()` as language construct deprecated would be easier if there would be an actual function replacement like `array_destruct()` that would address the readability argument (which is hard to discuss away because it is hyper subjective). Generally, there is nothing wrong with having a short and long syntax -- we do have the same with control flows and such. Of course I don't mean to ask you to withdraw the deprecation proposal here. However, in case it fails the above perhaps could bring this forward (probably together with solutions for `array()` and `var_export()` :)).
-- Cheers Nick

Seifeddine Gmati

61 days ago
> You said in one of your answers something like "one project holding back > the PHP language". While in essence true, Wordpress is not just any > project -- it's still the biggest multiplicator for PHP usage. The > amount of deprecation logs printed on a daily basis, the amount of > support generated, and the general impact will be huge.
I'll be honest, the size of the project isn't the part I find relevant. The objection only works if you assume a chain that doesn't actually happen: that merging this deprecation means every WP instance upgrades, that PHP 9.0 appears out of nowhere, and that apps break the next morning. None of those steps are automatic or imminent. A deprecation in 8.6 emits a notice; it is not an error and nothing stops working, regardles of how many `list()` instances are in the codebase. Actual removal is 9.0, which is years away. And instances don't upgrade themselves. A site must be actively moved onto a version that removed the construct before anything can break, and a site nobody maintains isn't being moved anywhere. So the "huge impact" is, at worst, deprecation notices in logs during a multi-year window that exists precisely to absorb them. That's true whether WordPress has one instance or a hundred million; the count doesn't change what a notice is. No project steers the language for me, WordPress included. but I don't even need that principle here. The scenario people are picturing just isn't the one the deprecation cycle produces.
> `array_destruct()` that would address the readability argument (which is > hard to discuss away because it is hyper subjective).
This can't work, and not for stylistic reasons. Destructuring happens in a *write* context: the construct sits on the left of `=` and receives bindings. A function can't do that. `array_destruct($a, $b) = $arr` isn't expressible, functions return values, they don't accept assignment targets. So a function couldn't replace `list()`; you'd need a new *construct* to stand in for it, which means adding grammar rather than removing it. That's the opposite of what the RFC is trying to do. This is also the crux of the readability point, I think: `list()` looks like a function precisely because of the parentheses, but it isn't one, and that mismatch is part of what makes the name misleading in the first place.

Nick

61 days ago
On 02.07.26 11:51, Seifeddine Gmati wrote:
>> `array_destruct()` that would address the readability argument (which is >> hard to discuss away because it is hyper subjective). > This can't work, and not for stylistic reasons. Destructuring happens > in a *write* context: the construct sits on the left of `=` and > receives bindings. A function can't do that. `array_destruct($a, $b) = > $arr` isn't expressible, functions return values, they don't accept > assignment targets. So a function couldn't replace `list()`; you'd > need a new *construct* to stand in for it, which means adding grammar > rather than removing it. That's the opposite of what the RFC is trying > to do. This is also the crux of the readability point, I think: > `list()` looks like a function precisely because of the parentheses, > but it isn't one, and that mismatch is part of what makes the name > misleading in the first place.
Fair enough. I had no idea it couldn't be done. Agreed that adding another language construct doesn't make sense; only the naming isn't enough.

Tim Düsterhus

61 days ago
Hi Am 2026-07-02 05:51, schrieb Seifeddine Gmati:
>> `array_destruct()` that would address the readability argument (which >> is >> hard to discuss away because it is hyper subjective). > > This can't work, and not for stylistic reasons. Destructuring happens > in a *write* context: the construct sits on the left of `=` and > receives bindings. A function can't do that. `array_destruct($a, $b) = > $arr` isn't expressible
That specific syntax would indeed not be possible, but the following would work: <?php function destruct(array $a, &...$results) { foreach ($results as $key => &$val) { $val = $a[$key]; } } destruct([1, 2, 3, 'b' => 'b'], $a, b: $b); var_dump($a, $b); see: https://3v4l.org/ia489n#veol Best regards Tim Düsterhus

Ilia Alshanetsky

64 days ago
On Mon, Jun 22, 2026 at 9:19 AM Gina P. Banyard <internals@gpb.moe> wrote:
> We still have a bit of time anyone else to propose additional > deprecations, and if you have write access feel free to add them directly > to the RFC. > Please note that with the new RFC policy rules the RFC must be finalized > and in a "frozen" state by the 13th of July at the latest. >
Before I add it to the RFC, I wanted to get a quick temperature check on whether people think it is finally time to deprecate and eventually remove open_basedir? The argument is that it's an old "hack" designed in an era when most people ran php on shared hosts via mod_php (Apache) under the same username, necessitating a way to separate users. For any hosting provider prioritizing security, better solutions exist now (VPC, php-fpm with different user pools, etc...) Therefore, this solution has outlived its usefulness and only adds complexity & overhead to file operations across the codebase.
-- Ilia Alshanetsky Technologist, CTO, Entrepreneur E: ilia@ilia.ws T: @iliaa B: http://ilia.ws

Tim Düsterhus

64 days ago
Am 2026-06-29 19:07, schrieb Ilia:
> Before I add it to the RFC, I wanted to get a quick temperature check > on > whether people think it is finally time to deprecate and eventually > remove > open_basedir?
I would be very much in favor of it, but please make sure to find the (various) existing discussions to reference. Given the amount of related discussion that have happened before, it might also make sense to do this as its own RFC. Best regards Tim Düsterhus

Derick Rethans

64 days ago
On 29 June 2026 18:07:05 BST, Ilia <ilia@ilia.ws> wrote:
>On Mon, Jun 22, 2026 at 9:19 AM Gina P. Banyard <internals@gpb.moe> wrote: > >> We still have a bit of time anyone else to propose additional >> deprecations, and if you have write access feel free to add them directly >> to the RFC. >> Please note that with the new RFC policy rules the RFC must be finalized >> and in a "frozen" state by the 13th of July at the latest. >> > > Before I add it to the RFC, I wanted to get a quick temperature check on >whether people think it is finally time to deprecate and eventually remove >open_basedir?
Yes, but for PHP 9. cheers Derick

Tim Düsterhus

64 days ago
Hi Am 2026-06-29 19:33, schrieb Derick Rethans:
>> Before I add it to the RFC, I wanted to get a quick temperature check >> on >> whether people think it is finally time to deprecate and eventually >> remove >> open_basedir? > > Yes, but for PHP 9.
To make sure we're on the same page: Are you proposing that `open_basedir` should only be deprecated starting with PHP 9 (which means that the removal would happen in PHP 10)? Best regards Tim Düsterhus

Derick Rethans

62 days ago
On Mon, 29 Jun 2026, Tim Düsterhus wrote:
> Am 2026-06-29 19:33, schrieb Derick Rethans: > > > > Before I add it to the RFC, I wanted to get a quick temperature > > > check on whether people think it is finally time to deprecate and > > > eventually remove open_basedir? > > > > Yes, but for PHP 9. > > To make sure we're on the same page: Are you proposing that > `open_basedir` should only be deprecated starting with PHP 9 (which > means that the removal would happen in PHP 10)?
Sortof. I don't think it'd be good to deprecate it now, and then remove it next year — in case the next release will be PHP 9 instead of PHP 8.7. I think a year is not long enough as deprecation period for this one. cheers, Derick
-- https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social

Jakub Zelenka

63 days ago
Hi, On Mon, Jun 29, 2026 at 7:09 PM Ilia <ilia@ilia.ws> wrote:
> > On Mon, Jun 22, 2026 at 9:19 AM Gina P. Banyard <internals@gpb.moe> wrote: > >> We still have a bit of time anyone else to propose additional >> deprecations, and if you have write access feel free to add them directly >> to the RFC. >> Please note that with the new RFC policy rules the RFC must be finalized >> and in a "frozen" state by the 13th of July at the latest. >> > > Before I add it to the RFC, I wanted to get a quick temperature check on > whether people think it is finally time to deprecate and eventually remove > open_basedir? > >
There are valid use cases for open_basedir where it can improve security of the application. It just cannot be relied on as a sendbox in general sense but removing it would be a mistake IMHO - not even mentioning that it would require migration for many applications that might depend on it. So -1 on it especially with such a late notice. Kind regards, Jakub

Nick

63 days ago
On 22.06.26 21:13, Gina P. Banyard wrote:
> Hello internals, > > 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 > > As a reminder, this list has been compiled over the course of the past year by different people. > > And as usual, each deprecation will be voted in isolation. > > We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. > Please note that with the new RFC policy rules the RFC must be finalized and in a "frozen" state by the 13th of July at the latest. > > Some deprecations should be non-controversial, others a bit more. > If a deprecation is really controversial, it might warrant its own dedicated RFC or be dropped altogether. > > > Best regards, > > Gina P. Banyard
Hello Internals, I added *Deprecate using “namespace” as a class constant or static property name* to the RFC: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_using_namespace_as_a_class_constant_or_static_property_name
-- Cheers Nick

Nick

47 days ago
Hey everyone, after talking to Gina and Tim I would like to ask here if there would be any objections against me, under "minor change", removing the "deprecate static properties" part from my >Deprecate using "namespace" as a class constant or static property name< contribution to the RFC -- hence limiting the scope. Reason: for what my RFC intended deprecating using "namespace" as a static class property is not actually required; and using "class" as static property name is also legal although it is a reserved keyword. Not deprecating "name" in class constants would roughly lead to -50% from the impact analysis Juliette did. --- Cheers Nick On 30.06.26 03:39, Nick Sdot wrote:

Tim Düsterhus

47 days ago
Hi On 2026-07-16 12:55, Nick Sdot wrote:
> after talking to Gina and Tim I would like to ask here if there would > be any objections against me, under "minor change", removing the > "deprecate static properties" part from my >Deprecate using "namespace" > as a class constant or static property name< contribution to the RFC -- > hence limiting the scope. > > Reason: for what my RFC intended deprecating using "namespace" as a > static class property is not actually required; and using "class" as > static property name is also legal although it is a reserved keyword. > Not deprecating "name" in class constants would roughly lead to -50% > from the impact analysis Juliette did.
For this bulk deprecation RFC where each proposal is fully independent, I consider it acceptable to retract entire proposals until the last minute without being considered a change. For your case of removing an *independent sub-proposal of a deprecation proposal*, I consider an “informal poll” as you did to be acceptable to seek agreement on the narrowing - but any objection must be considered a hard-no. Personally I don't object against this specific change. Best regards Tim Düsterhus

Gina P. Banyard

56 days ago
On Monday, 22 June 2026 at 14:13, Gina P. Banyard <internals@gpb.moe> wrote:
> Hello internals, > > 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 > > As a reminder, this list has been compiled over the course of the past year by different people. > > And as usual, each deprecation will be voted in isolation. > > We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. > Please note that with the new RFC policy rules the RFC must be finalized and in a "frozen" state by the 13th of July at the latest. > > Some deprecations should be non-controversial, others a bit more. > If a deprecation is really controversial, it might warrant its own dedicated RFC or be dropped altogether.
Reminder that there is less than a single week for adding deprecations before the RFC needs to be in a frozen state. A few people have added new ones and some were sent directly to me which I just added. I also reordered some of the deprecations to group them together in somewhat more logical places. https://wiki.php.net/rfc/deprecations_php_8_6 If anyone has any issues or additional proposals they can still be added or amended. If none are added or amended, I will initiate a call to vote next week. Best regards, Gina P. Banyard

Rowan Tommins [IMSoP]

56 days ago
On 7 July 2026 12:54:29 BST, "Gina P. Banyard" <internals@gpb.moe> wrote:
>> https://wiki.php.net/rfc/deprecations_php_8_6 > >If anyone has any issues or additional proposals they can still be added or amended. >If none are added or amended, I will initiate a call to vote next week.
I just skimmed through the page, and counted 35 proposals, of which only 8 had any analysis or discussion of the impact on existing code. Several more have had discussions of their impact in this thread, but the conclusions have not been summarised in the RFC for voters to see. ---- As I stated previously, if the vote is called with the RFC in the current state, I will cast 27 "no" votes, and only examine the remaining 8 proposals in detail. ---- The reason we require votes to pass with a two-thirds majority is to maintain the status quo by default. Changes, whether they are adding features or removing them, need to be weighed on a balance of cost vs benefit. It is not reasonable to expect every voter to independently research the costs of every proposal. It is up to the person proposing each change to make an honest and informed case for that balance, rather than presenting only advantages or gut feelings. I urge everyone whose name is on this RFC to review its content with that in mind. Thanks, Rowan Tommins [IMSoP]

Gina P. Banyard

56 days ago
On Tuesday, 7 July 2026 at 14:51, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:
> On 7 July 2026 12:54:29 BST, "Gina P. Banyard" <internals@gpb.moe> wrote: > >> https://wiki.php.net/rfc/deprecations_php_8_6 > > > >If anyone has any issues or additional proposals they can still be added or amended. > >If none are added or amended, I will initiate a call to vote next week. > > > I just skimmed through the page, and counted 35 proposals, of which only 8 had any analysis or discussion of the impact on existing code. > > Several more have had discussions of their impact in this thread, but the conclusions have not been summarised in the RFC for voters to see. > > ---- > > As I stated previously, if the vote is called with the RFC in the current state, I will cast 27 "no" votes, and only examine the remaining 8 proposals in detail. > > ----
You are free to do as you please.
> The reason we require votes to pass with a two-thirds majority is to maintain the status quo by default. Changes, whether they are adding features or removing them, need to be weighed on a balance of cost vs benefit. > > It is not reasonable to expect every voter to independently research the costs of every proposal. It is up to the person proposing each change to make an honest and informed case for that balance, rather than presenting only advantages or gut feelings. > > I urge everyone whose name is on this RFC to review its content with that in mind.
There are no guidelines on what constitutes a "impact assessment". Especially as qualitative assessments or the cost of keeping it in the language seem to not count. Unless the people that actively care about this provide concrete methods on how RFC authors can do such an assessment that does not require downloading gigabytes (possibly even terabytes) of barely representative OSS code, building an AST or static analysis tool, and then interpreting result in a way that is suitable for the people that care, I will not be engaging in providing metrics for the sake of providing metric that bear no usefulness for certain proposals. Best regards, Gina P. Banyard

Rowan Tommins [IMSoP]

56 days ago
On 7 July 2026 16:40:00 BST, "Gina P. Banyard" <internals@gpb.moe> wrote:
> >There are no guidelines on what constitutes a "impact assessment". >Especially as qualitative assessments or the cost of keeping it in the language seem to not count.
I deliberately did not use the words "impact assessment". I said the proposals did not include "any analysis or discussion of the impact on existing code". I'm not talking about proposals where the discussion of impact doesn't meet some particular threshold. I'm talking about proposals where there's not even a single sentence discussing it. No attempt to think about who it might affect. Not even a wild guess. I do not think we should be removing features without thinking about who will be affected. I'm honestly shocked that that's a controversial opinion Regards, Rowan Tommins [IMSoP]

Unnamed Person

55 days ago
On 7-7-2026 18:28, Rowan Tommins [IMSoP] wrote:
> On 7 July 2026 16:40:00 BST, "Gina P. Banyard" <internals@gpb.moe> wrote: >> There are no guidelines on what constitutes a "impact assessment". >> Especially as qualitative assessments or the cost of keeping it in the language seem to not count. > I deliberately did not use the words "impact assessment". I said the proposals did not include "any analysis or discussion of the impact on existing code". > > I'm not talking about proposals where the discussion of impact doesn't meet some particular threshold. I'm talking about proposals where there's not even a single sentence discussing it. No attempt to think about who it might affect. Not even a wild guess. > > I do not think we should be removing features without thinking about who will be affected. I'm honestly shocked that that's a controversial opinion
My offer to assist with creating some insights into the potential impact of the proposed deprecations still stands. I believe that by strategically using the PHPCompatibility library [1], creating this type of insight should be fairly straight-forward for ~25 out of the current 36 proposals. The only reason I haven't done so yet, is that it's pretty time-consuming to run PHPCompatibility over large data sets and there are more things on my to-do list than just this. Side-note: Gina - I do see and appreciate the (hidden) costs of keeping certain features in the language. But costs goes both ways (cost of deprecating something across the ecosystem versus the costs of continued maintenance of the feature in the language). Smile, Juliette 1: https://github.com/PHPCompatibility/PHPCompatibility

Claude Pache

51 days ago
> Le 7 juil. 2026 à 13:54, Gina P. Banyard <internals@gpb.moe> a écrit : > > On Monday, 22 June 2026 at 14:13, Gina P. Banyard <internals@gpb.moe <mailto:internals@gpb.moe>> wrote: > >> Hello internals, >> >> 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 >> >> As a reminder, this list has been compiled over the course of the past year by different people. >> >> And as usual, each deprecation will be voted in isolation. >> >> We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. >> Please note that with the new RFC policy rules the RFC must be finalized and in a "frozen" state by the 13th of July at the latest. >> >> Some deprecations should be non-controversial, others a bit more. >> If a deprecation is really controversial, it might warrant its own dedicated RFC or be dropped altogether. > > Reminder that there is less than a single week for adding deprecations before the RFC needs to be in a frozen state. > A few people have added new ones and some were sent directly to me which I just added. > I also reordered some of the deprecations to group them together in somewhat more logical places. > > https://wiki.php.net/rfc/deprecations_php_8_6 > > If anyone has any issues or additional proposals they can still be added or amended. > If none are added or amended, I will initiate a call to vote next week. > > Best regards, > > Gina P. Banyard
Hi, Here are my remarks on some of a deprecation proposals: ## Returning from a finally block. I feel that the text doesn’t tell the real issue with the feature to be deprecated. As everyone knows, an exception is thrown with a `throw` statement, is caught with a `catch` block, and is propagated until it is caught or it crashes at the top of the call stack. However, the description above is incorrect, because of the wacky semantics that the designers of the feature gave to `return` in `finally` block. *This* is the problem: having a role that it supposed to be reserved to another construct. The role of the `finally` block is to run code unconditionally, not to stop propagation. ## Passing objects for $data parameter of http_build_query() As I understand, what is proposed to be deprecated, is not only passing an object to `http_build_query` (such as `http_build_query((object)['a' => 'b'])`), but also passing an array who has an object as value (possibly at some deep level) (such as `http_build_query(['x' => (object) ['y' => 'z']])`). The deprecation message isn’t clear about that situation, because in the second case, an array is passed for argument #1 to http_build_query(). ## Deprecate is_a with string when $allow_string is false It is true that passing specifically a string as first argument of is_a() when $allow_string is set to false, does not make sense. However the first parameter of `is_a()` is of type `mixed`, and it makes plenty of sense to pass a value of type `mixed` (i.e. of unknown type) as first argument of `is_a()` when $allow_string is set to false: it tests whether the value is an object and an instance of a given class. If we want to deprecate passing a string as first parameter (if $allow_string is true) in order to avoid confusion, I think we should deprecate everything that is not an object: because `is_a(true, 'bool')` does not test whether `true` is a `bool`. But I don’t know whether such a deprecation is reasonable. ## Deprecate is_substring_of with string when $allow_string is false Same remark as for `is_a`. I don’t think it makes sense to cherry-pick `string` when `mixed` is allowed. —Claude

Gina P. Banyard

50 days ago
On Saturday, 11 July 2026 at 21:19, Claude Pache <claude.pache@gmail.com> wrote: > ## Passing objects for $data parameter of http_build_query() > > As I understand, what is proposed to be deprecated, is not only passing an object to `http_build_query` (such as `http_build_query((object)['a' => 'b'])`), but also passing an array who has an object as value (possibly at some deep level) (such as `http_build_query(['x' => (object) ['y' => 'z']])`). The deprecation message isn’t clear about that situation, because in the second case, an array is passed for argument #1 to http_build_query(). I can't comment on other people's proposal, but I tried clarifying this one as it's one of my own. Indeed any object encountered during the traversal will emit a deprecation, I added a possible message to it. I've also provided a function that allows recursively traversing arrays/objects to apply get_object_vars() and produce a "clean" array that can be passed to http_build_query. Hope this addresses the remark. Best regards, Gina P. Banyard

Gina P. Banyard

50 days ago
On Tuesday, 7 July 2026 at 12:54, Gina P. Banyard <internals@gpb.moe> wrote:
> On Monday, 22 June 2026 at 14:13, Gina P. Banyard <internals@gpb.moe> wrote: > > > Hello internals, > > > > 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 > > > > As a reminder, this list has been compiled over the course of the past year by different people. > > > > And as usual, each deprecation will be voted in isolation. > > > > We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. > > Please note that with the new RFC policy rules the RFC must be finalized and in a "frozen" state by the 13th of July at the latest. > > > > Some deprecations should be non-controversial, others a bit more. > > If a deprecation is really controversial, it might warrant its own dedicated RFC or be dropped altogether. > > Reminder that there is less than a single week for adding deprecations before the RFC needs to be in a frozen state. > A few people have added new ones and some were sent directly to me which I just added. > I also reordered some of the deprecations to group them together in somewhat more logical places. > > https://wiki.php.net/rfc/deprecations_php_8_6 > > If anyone has any issues or additional proposals they can still be added or amended. > If none are added or amended, I will initiate a call to vote next week.
The RFC is now *frozen* no new proposals will be accepted. As some were added during the past week minimum of 2 weeks discussion is necessary. Amendments to existing proposals can be made ONLY IF they are minor changes according to the policy. I will initiate a call to vote next week on Monday (the 20th) for the following Monday (the 27th) so that the vote is done by the 10th of August. This should hopefully mean that most accepted proposals can land with 8.6.0beta1. Best regards, Gina P. Banyard

Gina P. Banyard

43 days ago
On Monday, 13 July 2026 at 17:04, Gina P. Banyard <internals@gpb.moe> wrote:
> > On Tuesday, 7 July 2026 at 12:54, Gina P. Banyard <internals@gpb.moe> wrote: > > > On Monday, 22 June 2026 at 14:13, Gina P. Banyard <internals@gpb.moe> wrote: > > > > > Hello internals, > > > > > > 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 > > > > > > As a reminder, this list has been compiled over the course of the past year by different people. > > > > > > And as usual, each deprecation will be voted in isolation. > > > > > > We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. > > > Please note that with the new RFC policy rules the RFC must be finalized and in a "frozen" state by the 13th of July at the latest. > > > > > > Some deprecations should be non-controversial, others a bit more. > > > If a deprecation is really controversial, it might warrant its own dedicated RFC or be dropped altogether. > > > > Reminder that there is less than a single week for adding deprecations before the RFC needs to be in a frozen state. > > A few people have added new ones and some were sent directly to me which I just added. > > I also reordered some of the deprecations to group them together in somewhat more logical places. > > > > https://wiki.php.net/rfc/deprecations_php_8_6 > > > > If anyone has any issues or additional proposals they can still be added or amended. > > If none are added or amended, I will initiate a call to vote next week. > > The RFC is now *frozen* no new proposals will be accepted. > As some were added during the past week minimum of 2 weeks discussion is necessary. > Amendments to existing proposals can be made ONLY IF they are minor changes according to the policy. > I will initiate a call to vote next week on Monday (the 20th) for the following Monday (the 27th) so that the vote is done by the 10th of August. > This should hopefully mean that most accepted proposals can land with 8.6.0beta1.
As said last week, I intend to open the vote next Monday (the 27th of July) for 2 weeks so that the vote is finished on time for 8.6. Best regards, Gina P. Banyard