Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117411
Message-ID: <e1d7e5d9-cfa0-f036-0d5b-b9a2defb8c53@gmail.com>
Date: Thu, 24 Mar 2022 09:32:59 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-GB
To: internals@lists.php.net
References: <22242169-a16d-5261-696c-3cf00b00336a@gmail.com>
 <0b322a3e-469a-7ed7-16e3-0b76287f4091@gmail.com>
 <623BAFB6.4000901@adviesenzo.nl>
In-Reply-To: <623BAFB6.4000901@adviesenzo.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [PHP-DEV] Re: [RFC] Deprecate and Remove utf8_encode and utf8_decode
From: rowan.collins@gmail.com (Rowan Tommins)

On 23/03/2022 23:39, Juliette Reinders Folmer wrote:
>
> While I agree the functions are often used incorrectly, what worries 
> me about this RFC is that the only viable alternatives for these 
> functions are in two optional extensions, which in practice will mean 
> lots of projects will need to start polyfilling the old functions 
> and/or start including a polyfill for one of the extensions, as they 
> can not rely on those optional extensions being turned on.
>

While I certainly understand this concern, the more I look into it, the 
less worried I am, because so many projects already require the mbstring 
extension. The list includes projects like PHPUnit, Laravel, Drupal, and 
phpBB. A lot of others will probably detect it at run-time, and disable 
certain functionality - WooCommerce lists it as required only for 
non-English sites, for instance.

There probably is a case for making mbstring always-on rather than 
optional, but that perhaps requires a bigger discussion around what a 
"minimum" PHP should include. Why is XML support not always enabled, for 
instance?

If these functions were proposed today, under better names but the same 
feature set, I don't think mbstring being optional would be accepted as 
reasoning for adding them to core. So the only reason to keep them is if 
they're widely (and successfully) used, which I've not found evidence for.


Regards,

-- 
Rowan Tommins
[IMSoP]