Am 24.03.2022 um 10:32 schrieb Rowan Tommins <rowan.coll...@gmail.com>: > 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. >>
[...] > 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. Don't get me wrong: I'm on the fence if deprecating and later removing is the right thing to do, I'm not completely against it. 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. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
