[RFC] [VOTE]

Hi

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

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.

Hi

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

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.

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,

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_filter

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

> 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.

• Weilin

Hello internals,

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

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