[RFC] Deprecations for PHP 8.6

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