On 22/03/2021 13:10, Sara Golemon wrote:
> * People who just want to replace calls to utf8_decode won't want to go
> through every call and make it exception safe.
>
Then they shouldn't use these replacements, it's not for them. It's
for people using iso-8859-1.
This is a non-sequitur. Someone using the function correctly to convert
to ISO 8859-1 may also be relying on the documented and consistent
error-handling behaviour. Substituting the character may not always be
the best approach, but in some cases it's more useful than discarding
the entire string, let alone aborting the entire process with an
unhandled Throwable.
The goal is only to not punish users by taking away a valid API that
they were using correctly (for those users who were using it correctly).
I'm sympathetic to that aim, but if the new function is not the same,
you *are* taking away the existing API, and introducing a new one.
Neither of the following seems like it would be accepted:
- Make utf8_decode() throw errors for unrepresentable characters.
- Introduce a function specifically for converting from UTF-8 to
Latin-1, if we didn't already have one.
So it feels questionable to me to design a new function, which is
neither compatible with what we have, nor a reasonable addition on its
own merits.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
