Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115949 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 46440 invoked from network); 4 Sep 2021 21:42:35 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Sep 2021 21:42:35 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BF73A1804F2 for ; Sat, 4 Sep 2021 15:19:24 -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.2 required=5.0 tests=BAYES_20,CTE_8BIT_MISMATCH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24971 185.25.184.0/22 X-Spam-Virus: No X-Envelope-From: Received: from vm1861.cust.netio.cz (micropro.cz [185.25.185.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)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 4 Sep 2021 15:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at vm1861.cust.netio.cz Received: from [192.168.50.2] (ip-217-030-071-084.aim-net.cz [217.30.71.84]) by vm1861.cust.netio.cz (Postfix) with ESMTPSA id 762CEA3B07 for ; Sun, 5 Sep 2021 00:18:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=micropro.cz; s=default; t=1630793931; bh=bXgKYSQWE3EmFYVbkKzTgao8gV+3NmtHM/DshKInO/M=; h=Date:From:Subject:To; b=mEaxaOR5ZEjOk3W3Hz5oceJltGYrb68rzFHv5wIv9WJRCkFC+vEdYKHDRmMbLCWAB 5z+dgbL9kOYf+c71hya64JlEzY/c7l72cW/Ta+Og/FIphuKW3Hy/Dk0TCWWqDULw5M xpmUFTr2DRa7Ot7JJLsO/dQbyt5IaR5HVmHEbg8Y= Message-ID: <372fba7e-882f-7d34-9f2a-458de53eede9@micropro.cz> Date: Sun, 5 Sep 2021 00:19:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Thunderbird/92.0 To: internals@lists.php.net Content-Language: en-US Organization: Micropro Software Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: New operator suggestion From: admin@micropro.cz (=?UTF-8?B?RGF2aWQgS29sw6HFmQ==?=) Hello, I would like to suggest a new PHP operator, which in my opinion PHP needs to become more stricter. At first, I invited nullish coalescing (??) operator, since it made my code shorter and easier to read. However, after some time, I realized that this is not a good way to go, since it makes my code much less strict. The nullish coalescing function is what I need, however what I don't want in some cases is its error suppression function. Here is an example I use a lot while generating forms: I have ?? operator here, mainly because prop2 can be undefined, but in a lot of cases I know that prop1 exists, or at least $var. Issue is, that there is no error outputted even when $var is undefined and I missed such errors a lot. In my opinion is not good to learn people to suppress whatever error might occur in the whole expression. Back to the suggestion - I suggest creating a new IFNULL operator, which will simply test if expression is null. If not, it returns left-hand part, if yes, it returns right-hand part. A suggested token for such operator is "??:" as a mix between "??" and "?:" tokens. Basically elvis token "?:" but with strict comparison to null, instead of loose comparison to false. With new suggested operator a safe way to write expression above, where I only expect prop2 to be undefined would look like this: $var->prop1?->prop2 ??: ''; Notice, that use of newer operator "?->" really fits here. It clearly marks, what I expect to be undefined and "??:" operator just takes the role of converting possible "null" into and empty string. What do you think about this? Is it worth to introduce this new operator to promote more strictness of PHP? Is it worth to create an RFC for this? I never did an RFC yet and has not much experience with C++, since I am mostly Delphi/PHP/JS developer, but I might try. Still, I would appreciate a help from someone willing and experienced in RFC creation. Thank you in advance for your opinions, David Kolář