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,
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_PROGRESSFUNCTIONforcurl_setopt()
Can you expand on this?
Thanks,
Nicolas
It is this time of year again where we proposed a list of deprecations to add in 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
On Mon, Jun 22, 2026 at 6:59 PM Juliette Reinders Folmer <
php-internals_nospam@adviesenzo.nl> 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_6Hi 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
On Mon, Jun 22, 2026 at 6:59 PM Juliette Reinders Folmer
<php-internals_nospam@adviesenzo.nl
mailto:php-internals_nospam@adviesenzo.nl> 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_6Unfortunately 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
Hi
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
Hi
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 ofmetaphone(), 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
Hi
[reordering the quoted parts for this reply to read more nicely]
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
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]
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 learnHow 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
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]
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
... <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
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
Hello internals,
It is this time of year again where we proposed a list of deprecations to add in 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]
The one that stands out to me at first glance is the
_()alias forgettext()
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]
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
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]
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_XFERINFOFUNCTIONinstead.
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
Per the PHP documentation for
CURLOPT_PROGRESSFUNCTION1:deprecated as of cURL 7.32.0. Use
CURLOPT_XFERINFOFUNCTIONinstead.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
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.
Hi
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
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.
Overall, everything looks good, however, i object (although not voting) to deprecating
inandout, because their position in generics type parameter does not require them to be reserved keyword, and there's no parser ambiguity.inouton the other hand does make sense to deprecate for potential future inout parameters because there's an ambiguity with untyped parameters ( ininout $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
Overall, everything looks good, however, i object (although not voting) to deprecating
inandout, because their position in generics type parameter does not require them to be reserved keyword, and there's no parser ambiguity.inouton the other hand does make sense to deprecate for potential future inout parameters because there's an ambiguity with untyped parameters ( ininout $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 ofpreg_match()) where the input value is explicitly discardedThus, 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.
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.
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)
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 tostr_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 bespl_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
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
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/changesRegards,
Sjoerd Langkemper
Please don't, it's used in userland also.
Cheers
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
Le mar. 23 juin 2026, 09:43, Sjoerd Langkemper sjoerd-php@linuxonly.nl a
écrit :
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
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 :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:
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,
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
On Fri, Jun 26, 2026 at 5:38 PM Sjoerd Langkemper sjoerd-php@linuxonly.nl
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
On Fri, Jun 26, 2026 at 5:38 PM Sjoerd Langkemper sjoerd-php@linuxonly.nl 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
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
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
It is this time of year again where we proposed a list of deprecations to add in 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);
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), butgettype()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
Hello internals,
It is this time of year again where we proposed a list of deprecations to add in 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 forgettext()
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
I think I am not in favour of the following:
- Deprecate returning from a finally block
If somebody uses a
returnin afinallyblock, 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
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.
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]
On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP]
imsop.php@rwec.co.uk 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.
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.
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 thelistkeyword 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 overlist(), 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
listkeyword for
potential future use, I do not see a sufficiently strong technical
reason to deprecatelist().
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.
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
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
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
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
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:
--
Cheers
Nick