Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113646
MIME-Version: 1.0
References: <f313c9c4-f8a2-0b39-7499-30620d80cecd@gmail.com>
In-Reply-To: <f313c9c4-f8a2-0b39-7499-30620d80cecd@gmail.com>
Date: Sun, 21 Mar 2021 15:32:36 +0100
Message-ID: <CAG9XoMR1b6Np445WWS999vuWirmAH7hZEaH1ntPBEbiHJ4Y-0w@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b9f3d105be0cd254"
Subject: Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?
From: benjamin.morel@gmail.com (Benjamin Morel)

--000000000000b9f3d105be0cd254
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 21 Mar 2021 at 15:18, Rowan Tommins <rowan.collins@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.

=E2=80=94 Benjamin

--000000000000b9f3d105be0cd254--