> On Mar 21, 2021, at 09:32, Benjamin Morel <benjamin.mo...@gmail.com> wrote: > > On Sun, 21 Mar 2021 at 15:18, Rowan Tommins <rowan.coll...@gmail.com> wrote: > >> I can see three ways forward: >> >> A) Raise a deprecation notice in 8.1, and remove in 9.0. Do not provide >> a specific replacement, but recommend people look at iconv() or >> mb_convert_encoding(). There is precedent for this, such as >> convert_cyr_string(), but it may frustrate those who are using the >> functions correctly. >> >> B) Introduce new names, such as utf8_to_iso_8859_1 and >> iso_8859_1_to_utf8; immediately make those the primary names in the >> manual, with utf8_encode / utf8_decode as aliases. Raise deprecation >> notices for the old names, either immediately or in some future release. >> This gives a smoother upgrade path, but commits us to having these >> functions as outliers in our standard library. >> > > Hi, I'm personally fine with A or B, both of which have pros & cons: > > - A is probably the cleanest way as, as you said, these functions should > never have existed (locked to a single encoding that will only benefit a > portion of users), but that's quite a BC break > - B has is less of a BC break as it gives users a chance to rename their > function calls, but leaves an oddity in the standard library > > I'm a bit worried that either way, we'll start seeing some "polyfills" > appear on Packagist to re-introduce the old functions, but at least they > will be gone from the core.
I prefer option A, and the emergence of userland polyfills doesn’t worry me. IMO, that’s the right way for the community to handle the BC break. Cheers, Ben
signature.asc
Description: Message signed with OpenPGP
