Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117413
Message-ID: <d4853f34-c15c-5a2e-299d-d1bffe382a8f@gmail.com>
Date: Thu, 24 Mar 2022 11:19:25 +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>
 <e1d7e5d9-cfa0-f036-0d5b-b9a2defb8c53@gmail.com>
 <19112CBA-7BA7-4AA8-95BF-76EE20ECE56C@cschneid.com>
In-Reply-To: <19112CBA-7BA7-4AA8-95BF-76EE20ECE56C@cschneid.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode
From: rowan.collins@gmail.com (Rowan Tommins)

On 24/03/2022 09:52, Christian Schneider wrote:
>> 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.
> This argument is somewhat broken: Not adding something because an alternative exists is not the same as removing something (requiring code changes) where an alternative exists.


Absolutely, and an earlier draft of my e-mail said that more explicitly, 
but I edited for conciseness. I was trying to make the distinction that 
we wouldn't want to tell new users "if you want to measure the length of 
the string, install ext/strlen"; but telling new users "if you want to 
convert encodings, install ext/mbstring" is probably reasonable.

You are absolutely right that that does *not* apply to *existing* uses 
of the functions, and there will be some proportion of users / libraries 
who were previously using these functions successfully, but do not have 
mbstring installed / required. I think the usage is low enough, and the 
install base of mbstring is high enough, that that won't affect many 
people; but it's hard to prove that conclusively.

In the end, we have to weigh two costs: the cost to *new* users of 
leaving these confusing functions in place; and the cost to some portion 
of *existing* users of forcing them to change their code, and possibly 
install ext-mbstring (or some alternative). Doing nothing is not 
automatically better.


> I have one issue with the wording in the RFC: While “Function utf8_encode is deprecated; check usage is correct and consider mb_convert_encoding or other replacement.” suggests to replace it, the part about checking the usage implies that if someone is sure about the correct usage it is fine to keep using utf8_encode(). But as the proposal wants to remove it for 9.0 I think this is somewhat misleading.


That's a fair point. The intention was to encourage people to look at 
whether they were using the function right in the first place, not 
blindly replace it with mb_convert_encoding, since the whole point of 
the deprecation is that they probably aren't. I'm not sure how to 
concisely say "replace with mb_convert_encoding if you actually need to, 
but maybe you can just delete this function call and your code will be 
better".


Regards,

-- 
Rowan Tommins
[IMSoP]