Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117686 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66541 invoked from network); 7 May 2022 09:52:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 May 2022 09:52:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EB6AF180041 for ; Sat, 7 May 2022 04:29:59 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8412 83.65.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from mail02.x-net.at (mail02.x-net.at [83.65.141.138]) (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, 7 May 2022 04:29:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail02.x-net.at (Postfix) with ESMTP id 13A7C380214; Sat, 7 May 2022 13:29:57 +0200 (CEST) Received: from mail02.x-net.at ([127.0.0.1]) by localhost (mail02.x-net.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id t_6GwVcAJYsv; Sat, 7 May 2022 13:29:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail02.x-net.at (Postfix) with ESMTP id B7D9D3803F8; Sat, 7 May 2022 13:29:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at x-t.at Received: from mail02.x-net.at ([127.0.0.1]) by localhost (mail02.x-net.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DQj7eeiFmCtJ; Sat, 7 May 2022 13:29:56 +0200 (CEST) Received: from [127.0.0.1] (213-225-2-104.nat.highway.a1.net [213.225.2.104]) by mail02.x-net.at (Postfix) with ESMTPSA id 85324380214; Sat, 7 May 2022 13:29:56 +0200 (CEST) Date: Sat, 07 May 2022 13:29:57 +0200 To: internals@lists.php.net, Craig Francis User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] NULL Coercion Consistency From: mel@dafert.at (Mel Dafert) On 7 May 2022 12:54:45 CEST, Craig Francis w= rote: >I will note that my RFC does not change NULL coercion (why I quoted the d= ocumentation), and I'm not against the other BC breaks where certain type c= oercions are clearly problematic=2E > >It was 8=2E1 which introduced this specific BC problem (with ignorable de= precation notices)=2E=2E=2E and while that change was to begin alignment wi= th user defined functions, it's the user defined functions that have been t= he oddity (i=2Ee=2E do not use NULL coercion, unlike other contexts, such a= s concatenation, =3D=3D comparisons, arithmetics, sprintf, print, echo, arr= ay keys)=2E Personally I think it should have been user defined functions t= hat worked with the "old and well known" coercion rules, and doing so would= have reduced complexity (i=2Ee=2E working in the same way)=2E =2E=2E=2E >But my focus is on upgrading existing code, and this one is difficult to = find and update (e=2Eg=2E the lack of tooling to help)=2E It is exactly user-defined functions that this RFC introduces breakage for= =2E The behaviour to throw on null in user-defined functions exists since PHP 7=2E0, and is being relied on=2E Changing these now would introduce behavi= our changes that are harder to find than new type errors=2E Using strict typing isn't an option either/would be just as much work as a= uditing the changes this would introduce=2E It may be that user-defined functions should have accepted null to begin w= ith in your opinion, but that still makes it a breaking change now=2E Regards,=20 Mel