Hello internals,
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.
Please remember that the wiki is only capable to handle a single vote at a time,
so each vote MUST be submitted individually.
Best regards,
Gina P. Banyard
Hi
On 2026-07-27 12:31, Gina P. Banyard wrote:
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
PHP: rfc:deprecations_php_8_6The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.
Please remember that the wiki is only capable to handle a single vote at a time,
so each vote MUST be submitted individually.
It seems the RFC title didn’t make it into the email subject. I'm sending this reply to fix the Subject for proper visibility. It's still before 13 UTC, so there's still two full week for the vote.
Best regards
Tim Düsterhus
On Mon, 27 Jul 2026 at 13:46, Tim Düsterhus <tim@bastelstu.be> wrote:
Hi
On 2026-07-27 12:31, Gina P. Banyard wrote:
> As announced last week I've opened the vote for the 8.6 mass
> deprecation RFC:
> PHP: rfc:deprecations_php_8_6
>
> The vote runs for two weeks and will close automatically on the 10th of
> August 2026 at 13:00:00 UTC.
>
> Please remember that the wiki is only capable to handle a single vote
> at a time,
> so each vote MUST be submitted individually.It seems the RFC title didn’t make it into the email subject. I'm
sending this reply to fix the Subject for proper visibility. It's still
before 13 UTC, so there's still two full week for the vote.Best regards
Tim Düsterhus
I have missed the "Deprecate define() with $case_insensitive being
specified" before it went to vote, but I wonder why do we need to
deprecate it. If the feature is gone and the deprecation happened
already in the past, then what's left is just to clean it up by
removing the redundant parameter. By removing the parameter we cannot
break any userland code, so modifying the warning message won't help
with anything.
On Mon, Jul 27, 2026, 7:49 PM Tim Düsterhus <tim@bastelstu.be> wrote:
Hi
On 2026-07-27 12:31, Gina P. Banyard wrote:
As announced last week I’ve opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6The vote runs for two weeks and will close automatically on the 10th of
August 2026 at 13:00:00 UTC.Please remember that the wiki is only capable to handle a single vote
at a time,
so each vote MUST be submitted individually.It seems the RFC title didn’t make it into the email subject. I’m
sending this reply to fix the Subject for proper visibility. It’s still
before 13 UTC, so there’s still two full week for the vote.
and even if it was not, we should allow it.
If we would not, it would be a complete non sense and we need to sit down to sort this out 
–
Pierre
@pierrejoye
Hi,
On 2026-07-27 12:31, Gina P. Banyard wrote:
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
PHP: rfc:deprecations_php_8_6
At the time I'm the only one who voted "no" on PHP: rfc:deprecations_php_8_6
As things currently stand, projects that rely on this functionality (notably symfony/http-client and php-http/message) will start triggering deprecation notices in PHP 8.6. There are no plans to expose the underlying behaviour in an alternative way, despite this concern being raised during the discussion period.
I believe we should provide such an alternative together with the deprecation, rather than expecting projects with 200M+ installations to "find an alternative, such as decoding it using code written in PHP".
My 2c.
Cheers
--
Matteo Beccati
Hi,
On Mon, Jul 27, 2026 at 9:11 PM Matteo Beccati <php@beccati.com> wrote:
Hi,
> On 2026-07-27 12:31, Gina P. Banyard wrote:
>> As announced last week I've opened the vote for the 8.6 mass
>> deprecation RFC:
>> PHP: rfc:deprecations_php_8_6
At the time I'm the only one who voted "no" on
PHP: rfc:deprecations_php_8_6As things currently stand, projects that rely on this functionality
(notably symfony/http-client and php-http/message) will start triggering
deprecation notices in PHP 8.6. There are no plans to expose the
underlying behaviour in an alternative way, despite this concern being
raised during the discussion period.I believe we should provide such an alternative together with the
deprecation, rather than expecting projects with 200M+ installations to
"find an alternative, such as decoding it using code written in PHP".
On a side note in this "official" thread, I added gd and gd2 image
related functions to the list. I suppose they don't need a vote, as I
don't see them either in the "removed" list. They will effectively not
be available in php 9. And GD itself will do a deprecation warning in
8.7.
Cheers,
--
Pierre
@pierrejoye
On Mon, Jul 27, 2026 at 4:09 PM Matteo Beccati <php@beccati.com> wrote:
Hi,
On 2026-07-27 12:31, Gina P. Banyard wrote:
As announced last week I’ve opened the vote for the 8.6 mass
deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_6
At the time I’m the only one who voted “no” on
https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_dechunk_filterAs things currently stand, projects that rely on this functionality
(notably symfony/http-client and php-http/message) will start triggering
deprecation notices in PHP 8.6. There are no plans to expose the
underlying behaviour in an alternative way, despite this concern being
raised during the discussion period.I believe we should provide such an alternative together with the
deprecation, rather than expecting projects with 200M+ installations to
“find an alternative, such as decoding it using code written in PHP”.
I think this should have not been proposed for deprecation yet. There are significant users of it and I just didn’t have time to properly look into the issues. So there might be options to get it fixed properly. So I think it should wait till it’s properly investigated.
Kind regards,
Jakub
Hello,
On Mon, Jul 27, 2026 at 11:27 PM Jakub Zelenka <bukka@php.net> wrote:
I think this should have not been proposed for deprecation yet. There are significant users of it and I just didn't have time to properly look into the issues. So there might be options to get it fixed properly. So I think it should wait till it's properly investigated.
I took a bit of time to actually check what is used, realistically,
beyond keywords presence stats.
I think there is some data/stats misinterpretation here. Being present
in a code base does not automatically mean it is used.
For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in
Guzzle and Symfony default to curl too. As curl is optional, I would
be surprised if a large majority of users do not have curl. Even more
surprised as, it is also a composer required dep.
Some SAPIs or php servers like FrankenPHP take over this as well
before PHP gets a hand on it. Please correct me here if my memory
fails here
From a http "end user" perspective, I would rather define that as
effectively not used.
The only part the deprecation does not address directly is the
fopen&co internal usages.
I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Cheers,
--
Pierre
@pierrejoye
Hi Pierre,
Il 28/07/2026 05:52, Pierre Joye ha scritto:
For example, Symfony's native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in
symfony/src/Symfony/Component/HttpClient/NativeHttpClient.php at bb5999123482057647a0831010d14b6b34fe443c · symfony/symfony · GitHub
FYI, Symfony has implemented a pure-PHP alternative in 8.2:
That's why your search pointed in the wrong direction. Pre-8.2 there are a couple of:
stream_filter_append(..., 'dechunk', \STREAM_FILTER_WRITE);
in the code, if for whatever reason the Curl client is not in use.
I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Yet, feedback on how to improve/mitigate was provided and ignored during the discussion period. Avoiding the deprecation on stream_filter_append(), as suggested, would have been nice.
Cheers
--
Matteo Beccati
Hey Matteo,
On Tue, Jul 28, 2026 at 2:36 PM Matteo Beccati <php@beccati.com> wrote:
Hi Pierre,
Il 28/07/2026 05:52, Pierre Joye ha scritto:
> For example, Symfony's native http client disable it by default as it
> fails/failed to work correctly with stream_select, according to the
> inline comment in
> symfony/src/Symfony/Component/HttpClient/NativeHttpClient.php at bb5999123482057647a0831010d14b6b34fe443c · symfony/symfony · GitHubFYI, Symfony has implemented a pure-PHP alternative in 8.2:
That's why your search pointed in the wrong direction. Pre-8.2 there are
a couple of:stream_filter_append(..., 'dechunk', \STREAM_FILTER_WRITE);
in the code, if for whatever reason the Curl client is not in use.
> I would go with keeping that deprecation, and if anything went off the
> radar, the major frameworks components will surely, or hopefully,
> provide the feedback required to revisit this deprecation before RC1.
Yet, feedback on how to improve/mitigate was provided and ignored during
the discussion period. Avoiding the deprecation on
stream_filter_append(), as suggested, would have been nice.
Thanks
I miss the 8.2 switch. That being said, deprecation is for php 9
removal as a target ideally. Keeping stream_filter_append that brings
little to support users to migrate to a final solution earlier. Half
baked deprecation can lead to missing places where implementation
should be updated (not in project mentioned here tho' but many
internal code out there).
Cheers,
--
Pierre
@pierrejoye
Hi
On Tue 28. 7. 2026 at 10:59, Pierre Joye <pierre.php@gmail.com> wrote:
Hey Matteo,
On Tue, Jul 28, 2026 at 2:36 PM Matteo Beccati <php@beccati.com> wrote:
Hi Pierre,
Il 28/07/2026 05:52, Pierre Joye ha scritto:
For example, Symfony’s native http client disable it by default as it
fails/failed to work correctly with stream_select, according to the
inline comment in
https://github.com/symfony/symfony/blob/bb5999123482057647a0831010d14b6b34fe443c/src/Symfony/Component/HttpClient/NativeHttpClient.php#L227FYI, Symfony has implemented a pure-PHP alternative in 8.2:
https://github.com/symfony/symfony/commit/dca372b185100e82c556a741a96cbae1538162f2
That’s why your search pointed in the wrong direction. Pre-8.2 there are
a couple of:stream_filter_append(…, ‘dechunk’, \STREAM_FILTER_WRITE);
in the code, if for whatever reason the Curl client is not in use.
I would go with keeping that deprecation, and if anything went off the
radar, the major frameworks components will surely, or hopefully,
provide the feedback required to revisit this deprecation before RC1.
Yet, feedback on how to improve/mitigate was provided and ignored during
the discussion period. Avoiding the deprecation on
stream_filter_append(), as suggested, would have been nice.Thanks
I miss the 8.2 switch. That being said, deprecation is for php 9
removal as a target ideally. Keeping stream_filter_append that brings
little to support users to migrate to a final solution earlier. Half
baked deprecation can lead to missing places where implementation
should be updated
This is exactly a half baked deprecation because we need to keep it for internal use anyway (it’s used http stream wrapper for chunked encoding) so this does not give us any code removal and we still need to maintain it. I don’t understand why we need to rush it as there is no real reason for that.
Also we cannot just decide not to deprecate it in RC. We would need extra approval from RM and then new RFC. We had exactly this sort of situation last year with __sleep and it was huge pain to change. It also took lots of our time that we could use for much more important stuff.
Kind regards,
Jakub
Hey Jakub,
On Tue, Jul 28, 2026 at 5:16 PM Jakub Zelenka <bukka@php.net> wrote:
This is exactly a half baked deprecation because we need to keep it for internal use anyway (it uses http stream wrapper for chunked encoding) so this does not give us any code removal and we still need to maintain it. I don’t understand why we need to rush it as there is no real reason for that.
Yes and no. Having internal uses only down the road is significantly
easier to deal with than having to support this from a userland
perspective. There is some time to think about it and make it cleaner
or safer to be used for the purpose of fopen/file_get_contents like
usages. But the select issues may remain, not sure yet. I don't think
this is something that can't be solved.
Also we cannot just decide not to deprecate it in RC. We would need extra approval from RM and then new RFC. We had exactly this sort of situation last year with __sleep and it was huge pain to change. It also took lots of our time that we could use for much more important stuff.
I hear you.
Important has very different lists depending who we talk to. And
everyone has time when it is possible, being paid to do it or in their
free time. Cumulated time to deal with something we know is broken and
we could fix in a decade or more surely used an order of magnitude
time for too many people than reveriting a deprecation or adapting it.
Even if it happens some RMs will need to deal with it, but you and
others are not alone, dropping a mail here does not hurt and I am sure
some, or I when I know the area, can jump in too. Communication is
sometimes hard but amazingly helpful :).
Cheers,
--
Pierre
@pierrejoye
Hi,
On Tue, Jul 28, 2026 at 3:50 PM Pierre Joye <pierre.php@gmail.com> wrote:
Hey Jakub,
On Tue, Jul 28, 2026 at 5:16 PM Jakub Zelenka <bukka@php.net> wrote:
This is exactly a half baked deprecation because we need to keep it for internal use anyway (it uses http stream wrapper for chunked encoding) so this does not give us any code removal and we still need to maintain it. I don’t understand why we need to rush it as there is no real reason for that.
Yes and no. Having internal uses only down the road is significantly
easier to deal with than having to support this from a userland
perspective. There is some time to think about it and make it cleaner
or safer to be used for the purpose of fopen/file_get_contents like
usages. But the select issues may remain, not sure yet. I don’t think
this is something that can’t be solved.
I actually resolved that select issue (if it’s what I think it is - limitation using select on filtered streams which I got rid of) in the current master so it will be part of 8.6. See https://github.com/php/php-src/pull/20540 .
Also we cannot just decide not to deprecate it in RC. We would need extra approval from RM and then new RFC. We had exactly this sort of situation last year with __sleep and it was huge pain to change. It also took lots of our time that we could use for much more important stuff.
I hear you.
Important has very different lists depending who we talk to. And
everyone has time when it is possible, being paid to do it or in their
free time. Cumulated time to deal with something we know is broken and
we could fix in a decade or more surely used an order of magnitude
time for too many people than reveriting a deprecation or adapting it.
Even if it happens some RMs will need to deal with it, but you and
others are not alone, dropping a mail here does not hurt and I am sure
some, or I when I know the area, can jump in too. Communication is
sometimes hard but amazingly helpful :).
The problem is that there wasn’t enough time to properly investigate if the things can be improved on the C side. There was just some bug and then immediate proposal to deprecate it without first not even realising that it’s used by chunked encdoing which I needed to point out. Then the idea was to deprecate it for user space only which I actually wasn’t against as I assumed there was a proper research into the the usage but that wasn’t the case because Nicolas then pointed out that it is used in Symfony but the deprecation proposal didn’t get removed.
What I think is that deprecation should be proposed only if there a deep knowledge of the problem and the context which I’m not sure is the case here (and in some other proposals as well).
Kind regards,
Jakub
On 27 July 2026 11:31:53 BST, "Gina P. Banyard" <internals@gpb.moe> wrote:
Hello internals,
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
PHP: rfc:deprecations_php_8_6
Since Juliette kindly added some raw usage data, but proposers have refused to spend any time looking at it, I would like to point out that one of the uses found for "is" as a keyword is in Hamcrest, a cross-language test assertion framework. The PHP version has 500 million installs tracked by Packagist.
The is() function is part of the design inherited from the original Java library, and is used in many of the examples in the README so is likely to be widely used in the wild: GitHub - hamcrest/hamcrest-php: PHP Hamcrest implementation [Official] · GitHub
I think we should think very carefully whether we can avoid disrupting that much code.
Rowan Tommins
[IMSoP]
Hi,
Seeing this discussion during the voting phase makes me think the discussion phase wasn’t properly completed yet, and I did a poor job in merging all opinions into a RFC proposal. I would rather not fuel the discussion any further, but I would prefer to let the voting play out.
Jakub Zelenka wrote:
The problem is that there wasn’t enough time
I don’t know your situation, but it seems you have quite a lot of work on your plate. Is there something I or anyone can do to reduce your load?
This is exactly a half baked deprecation because … this does not give us any code removal and we still need to maintain it.
This is true, but my goal was to prevent abuse of the dechunk filter in filter chain attacks, not to reduce maintainance load. See also my PR to make filter chain attacks more difficult: https://github.com/php/php-src/pull/22110
to properly investigate if the things can be improved on the C side.
I tried some solutions, the most promising here: https://github.com/php/php-src/pull/22548
There was just some bug and then immediate proposal to deprecate it without first not even realising that it’s used by chunked encdoing which I needed to point out.
For reference, this was in https://github.com/php/php-src/pull/22036, and there is some more information in https://github.com/php/php-src/issues/21983.
Regards,
Sjoerd Langkemper
On Jul 27, 2026, at 7:31 AM, Gina P. Banyard <internals@gpb.moe> wrote:
Hello internals,
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
PHP: rfc:deprecations_php_8_6The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.
Please remember that the wiki is only capable to handle a single vote at a time,
so each vote MUST be submitted individually.Best regards,
Gina P. Banyard
Nora isn't on the list, but she points out:
The text for the metaphone deprecation isn't fully right. It lists
"linguistics" as a replacement package, but that one actually uses
php-src's metaphone internally too. So it is affected by the
deprecation, not a replacement.
As demonstrated by:
<?php
require 'vendor/autoload.php';
\Linguistics\Phonetics::metaphone('foo');
Nora isn’t on the list, but she points out:
The text for the metaphone deprecation isn’t fully right. It lists
“linguistics” as a replacement package, but that one actually uses
php-src’s metaphone internally too. So it is affected by the
deprecation, not a replacement.As demonstrated by:
<?php require 'vendor/autoload.php'; \Linguistics\Phonetics::metaphone('foo');
Thanks for noticing.
Worth noticing that only the Phonetics::metaphone function use php’s
metaphone(). Also, that function is barely a bridge for applying
existent functions of PHP. All other advanced algorithms ain’t affected
by the metaphone deprecation.
My point in deprecating it is to stop using ancient metaphone algo as a whole.
And Linguistics offers loads of implementation. So this is still a replacement.
However, I do see the reason to make this clear in the RFC text.
I also forward this to Nora.
Hi
On 2026-07-27 15:22, Kamil Tekiela wrote:
removing the redundant parameter. By removing the parameter we cannot
break any userland code, so modifying the warning message won't help
with anything.
For native functions passing parameters in excess of the function’s arity will throw an `ArgumentCountError`:
php > define('X', 'X', true, 'extra');
PHP Warning: Uncaught ArgumentCountError: define() expects at most 3 arguments, 4 given in php shell code:1
Making it explicit (and deciding) that the parameter will go in PHP 9 is a good thing.
Best regards
Tim Düsterhus
On Monday, 27 July 2026 at 11:31, Gina P. Banyard <internals@gpb.moe> wrote:
Hello internals,
As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
PHP: rfc:deprecations_php_8_6The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.
Please remember that the wiki is only capable to handle a single vote at a time,
so each vote MUST be submitted individually.
As a reminder to everyone, one week remains for voting on the mass 8.6 deprecation RFC.
Best regards,
Gina P. Banyard
On Monday, 3 August 2026 at 19:22, Gina P. Banyard <internals@gpb.moe> wrote:
On Monday, 27 July 2026 at 11:31, Gina P. Banyard <internals@gpb.moe> wrote:
> Hello internals,
>
> As announced last week I've opened the vote for the 8.6 mass deprecation RFC:
> PHP: rfc:deprecations_php_8_6
>
> The vote runs for two weeks and will close automatically on the 10th of August 2026 at 13:00:00 UTC.
>
> Please remember that the wiki is only capable to handle a single vote at a time,
> so each vote MUST be submitted individually.As a reminder to everyone, one week remains for voting on the mass 8.6 deprecation RFC.
Hello internals,
After two weeks of voting, the votes of the "Deprecations for PHP 8.6" RFC were closed at 13:00 UTC.
The following proposals have been accepted:
- Deprecate returning from a finally block (39 yay, 3 nay, 4 abstention, 90.7%)
- Deprecate using let as an identifier (24 yay, 11 nay, 9 abstention, 68.6%)
- Deprecate using "namespace" as a class constant name (29 yay, 8 nay, 7 abstention, 78.4%)
- Deprecate using "is" as an identifier (29 yay, 10 nay, 6 abstention, 74.4%)
- Deprecate the possibility to name a function "readonly" (39 yay, 1 nay, 2 abstention, 97.5%)
- Deprecate using "_" as a constant and compile time alias (34 yay, 4 nay, 5 abstention, 89.5%)
- Passing objects for $array parameter of array_walk() and array_walk_recursive() (41 yay, 3 nay, 0 abstention, 93.2%)
- Passing objects for $options parameter of deflate_init() and inflate_init() (39 yay, 4 nay, 1 abstention, 90.7%)
- Passing objects as parameters to the ''zlib.inflate'' and ''zlib.deflate'' stream filters (38 yay, 4 nay, 2 abstention, 90.5%)
- Passing objects as parameters to the ''bzip2.decompress'' and ''bzip2.compress'' stream filters (38 yay, 4 nay, 2 abstention, 90.5%)
- Passing objects for $vars parameter of mb_convert_variables() (39 yay, 2 nay, 2 abstention, 95.1%)
- Passing objects for $data parameter of http_build_query() (21 yay, 10 nay, 13 abstention, 67.7%)
- Deprecate is_double() (40 yay, 2 nay, 2 abstention, 95.2%)
- Deprecate is_integer() (39 yay, 2 nay, 3 abstention, 95.1%)
- Deprecate is_long() (39 yay, 2 nay, 3 abstention, 95.1%)
- Deprecate doubleval() (38 yay, 2 nay, 4 abstention, 95.0%)
- Deprecate define() with $case_insensitive being specified (41 yay, 0 nay, 3 abstention, 100%)
- Deprecate is_subclass_of with string when $allow_string is false (37 yay, 0 nay, 7 abstention, 100%)
- Deprecate is_a with string when $allow_string is false (38 yay, 0 nay, 6 abstention, 100%)
- Deprecate strcoll() (39 yay, 2 nay, 4 abstention, 95.1%)
- Deprecate SORT_LOCALE_STRING flag for sort() functions (38 yay, 2 nay, 3 abstention, 95.0%)
- Deprecate Metaphone Function (20 yay, 8 nay, 16 abstention, 71.4%)
- Deprecate ReflectionProperty::setValue() and ReflectionProperty::setRawValue() with wrong types (43 yay, 1 nay, 2 abstention, 97.7%)
- Deprecate ReflectionMethod::invoke() and ReflectionMethod::invokeArgs() with objects for static methods (39 yay, 3 nay, 1 abstention, 90.7%)
- Deprecate ArrayIterator methods that inherit ArrayObject implementation (42 yay, 1 nay, 0 abstention, 97.7%)
- Deprecate spl_classes() (43 yay, 0 nay, 0 abstention, 100%)
- Deprecate spl_object_hash() (26 yay, 9 nay, 11 abstention, 74.3%)
- Deprecate SplFileObject CSV methods (25 yay, 5 nay, 15 abstention, 83.3%)
- Deprecate mysqli::stmt_init (40 yay, 0 nay, 3 abstention, 100%)
- Deprecate mysqli_get_charset() (43 yay, 0 nay, 0 abstention, 100%)
- Deprecate passing a $sessionhandler object to session_set_save_handler() which does not contain the create_sid() and validateId() methods (26 yay, 2 nay, 14 abstention, 92.9%)
And the following proposals have been rejected:
- Deprecate the list() construct (23 yay, 23 nay, 1 abstention, 50.0%)
- Deprecate using "in", "out", and "inout" as identifiers (8 yay, 21 nay, 15 abstention, 27.6%)
- Deprecate using "_" as a function name and the _() function alias for gettext() (10 yay, 22 nay, 11 abstention, 31.3%)
- Deprecate dechunk filter (18 yay, 15 nay, 12 abstention, 54.5%)
Thank you to everyone that has voted and participated in the discussions.
Best regards,
Gina P. Banyard