Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95183
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
To: internals@lists.php.net
References: <CAGa2bXYGUhihdbMMBQB7FQ6CnmYqrB_x2YVjdZTvT8gDs59oOQ@mail.gmail.com>
 <6163e94b-9b42-0049-1346-3e7f790801a2@gmail.com>
Message-ID: <ffb07d7d-f37a-8740-255a-956cd3a5eb13@gmail.com>
Date: Mon, 15 Aug 2016 11:47:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <6163e94b-9b42-0049-1346-3e7f790801a2@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and
 utf8_encode()
From: rowan.collins@gmail.com (Rowan Collins)

On 15/08/2016 06:26, Stanislav Malyshev wrote:
> Hi!
>
>> Hi all,
>>
>> utf8_decode() and utf8_encode() are not needed and causing
>> problems than solving.
>
> Why you think they are not needed?

I'm guessing this came about from their mention on another thread. To
quote myself:

> utf8_decode()/utf8_encode are, at best, extremely misleading names.
> Many uses of them in my experience go something like this: "I have an
> encoding problem, it's something to do with UTF-8, I'll try
> utf8_encode; hm, that didn't work, I'll try utf8_decode instead".

They are certainly used in many, many places; but I would wager that 
almost all of those uses are broken because they make no effort to 
confirm that 8859-1 is the right source / target encoding. I think 
deprecating (but not removing) them might be sensible, because it would 
discourage this broken logic.

They are also trivially polyfillable; and again, anyone doing so will 
probably realise they misunderstood them and shouldn't be using them in 
the first place.

Regards,
-- 
Rowan Collins
[IMSoP]