Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118464 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42137 invoked from network); 24 Aug 2022 16:27:08 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Aug 2022 16:27:08 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A43431804A9 for ; Wed, 24 Aug 2022 11:32:28 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, 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-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) (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 ; Wed, 24 Aug 2022 11:32:25 -0700 (PDT) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-3375488624aso453584337b3.3 for ; Wed, 24 Aug 2022 11:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=o9pWppNL+r56uPMnrDuMnwhi9R3tZOVQAHSzeK/DXUk=; b=YuFhjIOsTW+6H3ESlAjTZkUSnOgiR9yr0QJckCXns912/FthyREoP80gcfD5drqOWa CVRunEC7LmNYXMHC8kRtk6KnSRCy3ZgqOmx3f534Ul7Jl7wed5Gd4v6OsAlpuBGhhC4D rfGnAGfGrX+Fmd/IDN2Fj+2m2tdjIcdOnH/PWAKj0weyQLWf1gJr6udeDsAAwjjsERLO /R5X6PHeFXR15m2+1BsX/L/k/m5aMwYJjCMBlDJKbfvTVvlxCnRExCv18q34Vn8o8htv Xft0I8gnNkfdCrIrXoW11PHHbA6zD6LYUWZ1CgjhhFxvGETh7K3DP5Epw8P3wlutNt6C Zgog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=o9pWppNL+r56uPMnrDuMnwhi9R3tZOVQAHSzeK/DXUk=; b=pT0IvnbwoJ8xIh1dMHanz0jFvOJyQ3tqUrNads8c1kcQR+vS6qm5wNJzhNwSW9B26L YX//uPnMPacFkscrxKeTHZTVciicwKIq1Qw4KUdIEoljxbtQOwiW5FShDbW6vm2upyaJ 1UNKNFcC9OFcj+WjeC2nlrnQcryi0ZLwjlbn0m0YnIdTvcki/3WIRD0P8ruWUhNUb9yt BSpRrfQzwZ24O6mA4qLKjhM0Y8bt+RLszsSgayAE4uudSS+vqex8oZhsGB/bim2ejhz7 CK1CuwmrP6l7LIhNCcnDUu/qUS5HRSrHm5pp812WdpF6G8CNn0nxV47UHSCfu4X57KZh Q7VA== X-Gm-Message-State: ACgBeo3kmJI+z90JP7A9eoHc59JdfSrXVHixFKmkvpZSvKIpUt7gp/bS MB4lq6xhtoNLHvacVyLeu9I1QNxdfGTFCDChuL4= X-Google-Smtp-Source: AA6agR7QaOUnSFP3++kwG0BQzCtaT3KreSXgwti5ATJFkt6dI8i4wHZKdueOwjDZsNK1RllujLOXivRI0YBdS3dTy2g= X-Received: by 2002:a0d:c042:0:b0:324:92a5:b81c with SMTP id b63-20020a0dc042000000b0032492a5b81cmr511279ywd.208.1661365944720; Wed, 24 Aug 2022 11:32:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 24 Aug 2022 21:32:12 +0300 Message-ID: To: Marco Pivetta Cc: Gert de Pagter , PHP internals Content-Type: multipart/alternative; boundary="000000000000fa229a05e700e64e" Subject: Re: [PHP-DEV] Nullsafe array access can still emit a warning From: zsidelnik@gmail.com (Eugene Sidelnyk) --000000000000fa229a05e700e64e Content-Type: text/plain; charset="UTF-8" I completely agree with Marco. We should not mix up nullsafe operator with array access. As for me, aforementioned code works as expected. As an improvement, we can think of access-safe operator (like `$arr[?0]`), however I'm not sure if introduction of such will make sense. Regards Yevhen On Wed, Aug 24, 2022, 4:11 PM Marco Pivetta wrote: > Hey Gert, > > On Wed, 24 Aug 2022 at 14:59, Gert de Pagter wrote: > > > Hi Internals, > > > > I recently learned that using null safe on an array access can still > > emit a warning when the array access is not defined. I kinda expected > > it to work like a null coalesce and just short circuit there,without > > the warning. > > > > Is there any chance this behaviour could be changed in a n upcoming > > PHP version? I didn't see anything mentioned specifically about this > > in the RFC. > > > > https://3v4l.org/1raa8 > > > > Greetings, > > Gert de Pagter/ BackEndTea > > > > This seems expected behavior to me: it's "nullsafe", not "undefinedsafe". > > If it operated like `??`, then `$undefined?->bar()` would be valid too, > which seems wrong, IMO. > > Marco Pivetta > > https://twitter.com/Ocramius > > https://ocramius.github.io/ > --000000000000fa229a05e700e64e--