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. — Benjamin
