[RFC] [VOTE]

On Mon, 27 Jul 2026 at 13:46, Tim Düsterhus <tim@bastelstu.be> wrote:

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:

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 :)

Hi,

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

&gt; Nora&nbsp;isn't&nbsp;on&nbsp;the&nbsp;list,&nbsp;but&nbsp;she&nbsp;points&nbsp;out: &gt; &gt; The&nbsp;text&nbsp;for&nbsp;the&nbsp;metaphone&nbsp;deprecation&nbsp;isn't&nbsp;fully&nbsp;right.&nbsp;It&nbsp;lists &gt; "linguistics"&nbsp;as&nbsp;a&nbsp;replacement&nbsp;package,&nbsp;but&nbsp;that&nbsp;one&nbsp;actually&nbsp;uses &gt; php-src's&nbsp;metaphone&nbsp;internally&nbsp;too.&nbsp;So&nbsp;it&nbsp;is&nbsp;affected&nbsp;by&nbsp;the &gt; deprecation,&nbsp;not&nbsp;a&nbsp;replacement. &gt; &gt; As&nbsp;demonstrated&nbsp;by: &gt; &gt; <?php &gt; require&nbsp;'vendor/autoload.php'; &gt; \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

On Monday, 3 August 2026 at 19:22, Gina P. Banyard <internals@gpb.moe> wrote:

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