Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117412 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91947 invoked from network); 24 Mar 2022 08:25:33 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Mar 2022 08:25:33 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A2DEF18053E for ; Thu, 24 Mar 2022 02:52:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS1836 195.49.0.0/17 X-Spam-Virus: No X-Envelope-From: Received: from darkcity.gna.ch (darkcity.gna.ch [195.49.47.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 24 Mar 2022 02:52:29 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:1210:2ea4:cf00:8dc3:ea53:13b3:9dd1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 7D3C81516030 for ; Thu, 24 Mar 2022 10:52:26 +0100 (CET) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Date: Thu, 24 Mar 2022 10:52:26 +0100 References: <22242169-a16d-5261-696c-3cf00b00336a@gmail.com> <0b322a3e-469a-7ed7-16e3-0b76287f4091@gmail.com> <623BAFB6.4000901@adviesenzo.nl> To: php internals In-Reply-To: Message-ID: <19112CBA-7BA7-4AA8-95BF-76EE20ECE56C@cschneid.com> X-Mailer: Apple Mail (2.3696.80.82.1.1) Subject: Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode From: cschneid@cschneid.com (Christian Schneider) Am 24.03.2022 um 10:32 schrieb Rowan Tommins : > On 23/03/2022 23:39, Juliette Reinders Folmer wrote: >>=20 >> While I agree the functions are often used incorrectly, what worries = me about this RFC is that the only viable alternatives for these = functions are in two optional extensions, which in practice will mean = lots of projects will need to start polyfilling the old functions and/or = start including a polyfill for one of the extensions, as they can not = rely on those optional extensions being turned on. >>=20 [...] > If these functions were proposed today, under better names but the = same feature set, I don't think mbstring being optional would be = accepted as reasoning for adding them to core. So the only reason to = keep them is if they're widely (and successfully) used, which I've not = found evidence for. This argument is somewhat broken: Not adding something because an = alternative exists is not the same as removing something (requiring code = changes) where an alternative exists. Don't get me wrong: I'm on the fence if deprecating and later removing = is the right thing to do, I'm not completely against it. I have one issue with the wording in the RFC: While =E2=80=9CFunction = utf8_encode is deprecated; check usage is correct and consider = mb_convert_encoding or other replacement.=E2=80=9D suggests to replace = it, the part about checking the usage implies that if someone is sure = about the correct usage it is fine to keep using utf8_encode(). But as = the proposal wants to remove it for 9.0 I think this is somewhat = misleading. Regards, - Chris