Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119132 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94623 invoked from network); 13 Dec 2022 16:59:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Dec 2022 16:59:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 58E2E180538 for ; Tue, 13 Dec 2022 08:59:48 -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.1 required=5.0 tests=BAYES_00,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-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 13 Dec 2022 08:59:47 -0800 (PST) Received: by mail-wr1-f43.google.com with SMTP id h16so7351133wrz.12 for ; Tue, 13 Dec 2022 08:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=xF5ubknPCIAFCaikJRbXCwZLwc6tbeQVIm+ArUb+/X4=; b=dDgj6hhXDBPFk0K8VqvcqWA31gU18or+cATEsaMeEzU5uznwpv4ivkb9BXDKUO0STc aTvvDX5f/EgdTKHPxWr0TUG5BZ7KjO2DiraVS/LUCbdIhi7uk3Vw95x12ZQTC3fMNzfF 0g78QkIFfD/82sshRfuBb4Mbn0PU3JYALH7/fZ1PZG1VHvmwHGH1ldoJkTt9Kbj8tM8O TEJtD2+nqSBk32/tENS4eY035s1ikOrJ4VKg8rWoPSl44paNFrmLRTQy5nougzQaizZ4 xSq1L90jPDaYt1A4q7s77+mp8BraQ/5ZYmaBeWovKzL0Vvq4gdNWYlrv+76lYZajgf2Z a2gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xF5ubknPCIAFCaikJRbXCwZLwc6tbeQVIm+ArUb+/X4=; b=7/JR3J0HgTAWXMxiDXSvRqUU7S8lBr9QZQQIRK25XPL3jncN3TOBS+gd85ZbrPWyu1 gWpJ4ILaEf9EAjvMwBTYXmamDD34baPGusgNmUXqNettmRqVkFsT0hxpcUb1tWQN6I+W IKBHWHMHtzz/n4WT0TdbZJFXxRbYE67fk9o72ZySg3c/qYZABymhZ96L5PbnZPS8sIcm zvOSK1hGjhUwrFSCAnAyKBc9zhLGBCcaTwy8JeatOumzLbLgloOkMbuHj/clCktrA7yd PQ1damqyLiqK7FUOFdLvltgNawAS8pJ9y3KnpJDKDZEGMvELtXl6LBxHoJu4E9H/Sh+f ncKw== X-Gm-Message-State: ANoB5pmTTQDI9y6WF6k0CK67bhBTvOgsR4RHlUMgeOAXIbXxcMN47fBi N4C52eeDDvSmvMsDoKPG7aCP063mV1A= X-Google-Smtp-Source: AA0mqf793zbaq6Kd2gCAD/LCveOErWI8jGWmvWjZGZmbMdOp8q5lDRecc2GQkFcrMxgTDnfYMd8mkA== X-Received: by 2002:a5d:48cf:0:b0:241:b6d2:7efb with SMTP id p15-20020a5d48cf000000b00241b6d27efbmr14148278wrs.27.1670950786723; Tue, 13 Dec 2022 08:59:46 -0800 (PST) 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 h8-20020adff4c8000000b00241f029e672sm231593wrp.107.2022.12.13.08.59.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Dec 2022 08:59:46 -0800 (PST) Message-ID: Date: Tue, 13 Dec 2022 16:59:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Content-Language: en-GB To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index From: rowan.collins@gmail.com (Rowan Tommins) On 13/12/2022 16:08, Dan Liebner wrote: > Can I also just point out that by current definitions the "null coalescing > operator" isn't properly named, it should be the "undefined/null coalescing > operator". The only reason it is able to get away with not raising an error > for undefined variables is that it's described as "syntactic sugar" for > isset(), which is itself the exception to the rule for not raising > undefined errors.Other languages, such as JavaScript, would raise an error > for an expression such as `undefinedvar ?? 0`. And JavaScript conveniently > offers the undefined primitive for precisely handling attempted accesses of > undefined keys, while retaining the brevity and convenience of a > truthy/falsy `obj.key` check. Can you expand a bit on how you think distinguishing "undefined" from "null" would help? Let's keep the focus on possible solutions, not just arguing in circles. It's always been a source of confusion to me that JS has both, and the syntax for working them seems far from elegant (unless things have improved, and you no longer need to use typeof to detect undefined?); but maybe I'm looking at it wrong. Regards, -- Rowan Tommins [IMSoP]