Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117154 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 25111 invoked from network); 27 Feb 2022 14:10:37 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Feb 2022 14:10:37 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 4BF251804C3 for ; Sun, 27 Feb 2022 07:31:22 -0800 (PST) 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,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS19151 66.111.4.0/24 X-Spam-Virus: No X-Envelope-From: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 ; Sun, 27 Feb 2022 07:31:22 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DB84C5C00F2 for ; Sun, 27 Feb 2022 10:31:21 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Sun, 27 Feb 2022 10:31:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=v1z8QesIGxIsqaFN0 mHdnRX4vGq5ym+A7UgvkilnaO0=; b=FvQ85aPUzANV//NiCkT79eiaXgRPtRAPL gizzH/86Pv7xoLmZkLfHnvX3A6Ch5JzsXYzd5uPRsdzwmN+mnU9Adg19N7asq/ut J5XkNLcpW7tRo8pJkJxpZIzW9QepgDvz2sLFSUMZvbmtY9Y1A8PqbbijTrfqYQrS g1CM8ePsO61+EPB3MXZjiksgN8oa/jN1OW4OQmW71vD/t9DXxg3ilWr4YeCHWo4v VwLh2XzlQSrvQD4jYWBXTMPVpUYQM8tht2aPlGfKWWHHtSWZZqVq3pHah75ugq9+ oKVN/9jQ3POO0DvblLuGGbZKzu7SzwCjM9D1sXW0+bl5WzPgpu85g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrleekgdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuggftrfgrthhtvghrnhepgeelgfekudeivddvteffueejffdthfejieevhefgffek udevkedtvdelvddvffefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9AAABAC0E99; Sun, 27 Feb 2022 10:31:21 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997 Mime-Version: 1.0 Message-ID: In-Reply-To: References: <621a56dd.1c69fb81.67b1.242aSMTPIN_ADDED_MISSING@mx.google.com> <621ab36a.1c69fb81.b1a5.462dSMTPIN_ADDED_MISSING@mx.google.com> <621b6215.1c69fb81.ae9e6.4901SMTPIN_ADDED_MISSING@mx.google.com> Date: Sun, 27 Feb 2022 09:31:00 -0600 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] Re: Proposal for RFC to remove undefined arrayindexwarning when used ina ternary From: larry@garfieldtech.com ("Larry Garfield") On Sun, Feb 27, 2022, at 9:11 AM, Robert Landers wrote: > On Sun, Feb 27, 2022 at 12:35 PM Mark Randall wrote: > >> On 27/02/2022 09:12, Robert Landers wrote: >> > I'd also venture that this warning has caused more harm than good, in >> that >> > writing "$var['something'] ?? null" is second nature when writing new >> > code, even if there is practically no chance for a non-existent key. >> >> >> >> Using null coalesce should only be used when you know you have the >> possibility of a missing key. >> > > That can't always be known, or requires tracing the stack to see where > it comes from and what modifies the array before it is passed to the > function you are modifying, it is an array after all, not a formalized > object with well-defined properties (which I'd prefer, but we can't always > change what someone did 15 years ago just for the sake of changing it). If you want to assign defaults to missing array keys, this is a generally good approach I've used with much success: $arr = ['a' => 1, 'b' => 2]; $defaults = ['a' => 3, 'c' => 4]; $arr += $defaults; If you're stuck with a pseudo-object hash like that, this is a clean way to guarantee you have values for each key. That said, I'm also open to discussing null-safe array operators. I can see lots of uses for that. --Larry Garfield