Re: [RFC] Deprecate and Remove utf8_encode and utf8_decode

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]