Hello internals, After discussions with RMs the agreement is that the PR [1] can be merged if there is no objection within 1 week.
I'll recapitulate some of the history behind that RFC and delay in implementation. The original RFC [2] was approved for PHP 5.6 and slated for removal in PHP 7. (The original text says PHP 6, but this is because the choice to skip version 6 wasn't made yet.) However, it didn't get removed in PHP 7 due to a technical TODO which wasn't done in time. See following discussion: https://externals.io/message/103087. The various technical issues were fixed in PHP 7.4. However, when I submitted a PR to remove those INI settings for PHP 8.0 the short time span, confusion around those INI settings and behaviour and time constraints meant that it got punted to PHP 9. (There are a few Room 11 discussion from the time that can be found. [4][5]) Those INI settings have never been "undeprecated", and them being slated for deprecation is confirmed by the documentation. Specifically, the manual pages for the iconv [6] and mbstring [7] INI settings state the following: > This feature has been DEPRECATED as of PHP 5.6.0. Relying on this feature is > highly discouraged. and > This deprecated feature will certainly be removed in the future. respectively. Moreover, multiple discussion clearly talk about the nonsensical state of keeping the functions while removing the INI settings, because what would be the behaviour of the functions? Doing nothing? Affect the global INI settings? As such, those functions _should_ be deprecated as it can be seen as a natural follow-up, and something that was just forgotten to be explicitly stated in the RFC body. Which seems to be confirmed by an email by Yasuo (original author of the RFC) sent to the list in January 2015. [8] Therefore, I see no reason to delay a deprecation of those functions any further, especially considering that the existence of a version 8.6 has not yet been decided. Best regards, Gina P. Banyard [1] https://github.com/php/php-src/pull/19664 [2] https://wiki.php.net/rfc/default_encoding [3] [https://github.com/php/php-src/pull/533](https://github.com/php/php-src/pull/5334) [4] https://chat.stackoverflow.com/transcript/11?m=49250309#49250309 [5] https://chat.stackoverflow.com/transcript/11?m=50205227#50205227 [6] https://www.php.net/manual/en/iconv.configuration.php [7] https://www.php.net/manual/en/mbstring.configuration.php [8] https://externals.io/message/81099#81229 On Thursday, 4 September 2025 at 08:48, Jorg Sowa <jorg.s...@gmail.com> wrote: > Hello everyone, > I'm writing regarding the deprecation of mbstring/iconv encoding that was > voted on more than 10 years ago. > RFC: https://wiki.php.net/rfc/default_encoding > > It was accepted that following INI settings were deprecated: > "iconv.input_encoding (Default: php.input_encoding) > iconv.internal_encoding (Default: php.internal_encoding) > iconv.output_encoding (Default: php.output_encoding) > mbstring.http_input (Default: php.input_encoding) > mbstring.internal_encoding (Default: php.internal_encoding) > mbstring.http_output" > + enigmatic "all functions that take encoding option use > php.internal_encoding as default (e.g. htmlentities/mb_strlen/mb_regex/etc)" > Without INI values following functions are becoming pointless: > - iconv_set_encoding > - iconv_set_encoding > - mb_internal_encoding > - mb_http_output > > Function `mb_http_input` would likely require separate RFC. > > PRs[1] deprecating INI settings are already waiting for next major PHP > update, but the problem is with proper deprecation phase of those values. > There wasn't any since 5.6. So the decision of removal of those INI may be > controversial for now. > My suggestion is to properly deprecate all the INI settings + functions using > them before 9.0. The question is, does it require additional RFC, or this may > already have consensus, given the formal deprecation was agreed upon 10 years > ago, however without specified rules how it will be achieved? > Kind regards, > Jorg > > [1] https://github.com/php/php-src/pull/12445
