Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117434 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84325 invoked from network); 26 Mar 2022 20:55:12 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Mar 2022 20:55:12 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 57C0C1804BD for ; Sat, 26 Mar 2022 15:22:47 -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=-0.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 ; Sat, 26 Mar 2022 15:22:46 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id r190-20020a1c2bc7000000b0038a1013241dso6387304wmr.1 for ; Sat, 26 Mar 2022 15:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language :from:to:references:in-reply-to:content-transfer-encoding; bh=8BS+t03QYPx335URUcyAhUL02DRbCnkf5h16mPVR5AA=; b=RWPh8taf9WWC4/c5ML9+ZWmv33A0U8lphE66qbAVZZzYxCEbmg9IODsurqFQo49j6b jL2Z72gEw5AMDLgqmoHluwmihcF7HWiODUADcqEiusBt2N9T/QebDFSPDZC/Bcs3vrZG 6bUnXv1ljvBFOQO8Va6lG3mEdpu1F6jdlScJUlU6LLSKPQYaM0L4sZLAuaXnawzoejtH q1apG7m2IhDGFas9y/HwqrZr/YSLZtRcpVZPueJ7Cm+vFY0qQCHmF7b3R2FmklabXsvW od4o0LX5+VhvP4EJLIjDa6+NgDeTOwlSPgfYYwrgSHshTJn2klfVoJ7km/xMgs7KLlQV nnLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:references:in-reply-to :content-transfer-encoding; bh=8BS+t03QYPx335URUcyAhUL02DRbCnkf5h16mPVR5AA=; b=SUFS9G7aIYTg7zcoCcSlyhISqqXZqjPfHvuwdULnskLV0wuwd8Ycrk06r2R9SLKAE1 MJ1J7ZC7bNYbWJ+cjASOOJwqd/lHxdf7zwPJwk4BlxAhurGA4r5X9x3GT0u+QxJkosQo OEsRwpuXCsaSO5c2Gz69niiVxnjrWHQhVYXVsG9h1OyV3nasyxd/DEVdJ8nMnW0ZVWbO upk/UO6TMeBhO6K7hFqToSWH/EWbemyVf2bh/m5+702/7TyhGmiZjvNH4ndkca4OWQuf x1hICeB975rGhK01vwuIiA2G6lErLrgQcktiUnf5AF8bWfC+dFH4l16IJLQ5ilC/X9cd P/fA== X-Gm-Message-State: AOAM5329XQ5Ld48hv6ImmVf+6d0ahW8iSQ5UFLBfRpvJ5oNpePgY8/hf pwbz1v18hJra0U0M3ZZrsrxV+ghNdmk= X-Google-Smtp-Source: ABdhPJy+Jv91IP0EGAEBftG5YTd2FS+UOsNtQC6U5Tj/7jpQFHywnoUDDtVX9l8TaiVeqjQND8/vZQ== X-Received: by 2002:a05:600c:4f91:b0:38c:d65d:c90e with SMTP id n17-20020a05600c4f9100b0038cd65dc90emr14199583wmq.117.1648333365673; Sat, 26 Mar 2022 15:22:45 -0700 (PDT) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id u11-20020a056000038b00b00203e5c9aa09sm12251078wrf.27.2022.03.26.15.22.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Mar 2022 15:22:45 -0700 (PDT) Message-ID: Date: Sat, 26 Mar 2022 22:22:44 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-GB To: internals@lists.php.net References: <22242169-a16d-5261-696c-3cf00b00336a@gmail.com> <0b322a3e-469a-7ed7-16e3-0b76287f4091@gmail.com> <623BAFB6.4000901@adviesenzo.nl> <19112CBA-7BA7-4AA8-95BF-76EE20ECE56C@cschneid.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode From: rowan.collins@gmail.com (Rowan Tommins) On 24/03/2022 11:19, Rowan Tommins wrote: >> I have one issue with the wording in the RFC: While “Function >> utf8_encode is deprecated; check usage is correct and consider >> mb_convert_encoding or other replacement.” 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. > > > That's a fair point. The intention was to encourage people to look at > whether they were using the function right in the first place, not > blindly replace it with mb_convert_encoding, since the whole point of > the deprecation is that they probably aren't. I'm not sure how to > concisely say "replace with mb_convert_encoding if you actually need > to, but maybe you can just delete this function call and your code > will be better". Maybe I'm trying to be "too helpful" there. Should we just use the generic deprecation message, and let people look up the in-depth explanation in the manual? Anyone have any thoughts on that? Regards, -- Rowan Tommins [IMSoP]