Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:126308 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id ED2F31A00BC for ; Thu, 6 Feb 2025 12:50:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1738846088; bh=o3Jej2ttWIG/6S4DSyMrV0rLTO21/3A/litMbbWfH04=; h=References:In-Reply-To:From:Date:Subject:Cc:From; b=fBlf6yCIvUP7djKdJ04LQNerRSxB8psZXb7Rja2qmMC/WYoEPICx1rJ3IXgD/L9L/ YpIm11Hc5KjdKj60lL+AYyR/rYFnLErdki567bZu753YygAUcxucm7OJkSSu88+9P9 1RCZtp0R79x8Qen196fW11dGIvR7XaorSUJZgKVvKdYdILZc2fIUD8pEKhP/NhptVn AbZ8g2HrxlyFJv1qvnhfSvzkAT+2egpU/kcCXG2RCkLGC7TN0kbeL7+cOQRDI6sjKk 58UUhTmpNzq+6ZNx+U/HkEF3wCkQDH8fQ5Mz0A+k8H4tydfGj2+gndT6xd5jg+C2Gn o4VykPOMA0iuQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5549A18006A for ; Thu, 6 Feb 2025 12:48:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,MALFORMED_FREEMAIL,MISSING_HEADERS,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: <91liahim@gmail.com> Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 6 Feb 2025 12:48:06 +0000 (UTC) Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-6f006748fd1so7723417b3.3 for ; Thu, 06 Feb 2025 04:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738846251; x=1739451051; darn=lists.php.net; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=o3Jej2ttWIG/6S4DSyMrV0rLTO21/3A/litMbbWfH04=; b=Tw8gTnqF/cWuscllofy1p0jZ/3CP4iqGdK7eJsaAPUiQy8Ge3a66QRuWtKE+M9ShKd 70gKJy/2tGG+VMo4+PCifcfqe/YuGYraNgSzThDxSjyUWMWT+kT1U3T/io8C2q+VskCI O39MsVt9nROTRYww138MUB6hGDKlVANFBHF3tzYVzaPpKJx+F4MkMrabs9zSjOviX1BI CU4QNVyNVlEwvKJRPRl1q7LsF4RvFmm+e3YgJssFHWL+EtSS5QYJBsIuWosoE5cE1iem Hbsfky/dlKxlxQcvfuwmVvJqDy3wSjEq6WIxxO1bM0RlWXRxW6krVsLQHMeCA2mkAqGc nmqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738846251; x=1739451051; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o3Jej2ttWIG/6S4DSyMrV0rLTO21/3A/litMbbWfH04=; b=DAypV0VlnDc3yY3MrW+a53jx50riamrdxEwFRNMuYPbJPEE4gg2eMQECUOPotWavMb 7sfOm+ic9mZqqt0PqqiHUcgURZ2pCkU+pjT8K4CQ2jlzq4J02eoJyeDTm6lHi4dtY7HG /oHQ5iarSaM/hR+nb80vO4XgbzyG7i+/iGqR0blEMphew4o+15Upbe3c3wqDFG8Twr4a o+9etI3zO9OwqqhMINevRHfTmdL+0hJuAEsuCTJccY+445vIVyMR8ezp/17gJnLGnN1q SYsund2DesQF+QN5jJ4CWwirY4t6IUJaVZZY1NFzjuMOlehF1UQd3CLM+j1r3DgxRTDL YZSQ== X-Gm-Message-State: AOJu0YwNyFGAH0AZOCCNgVlXHL62RjmdmLBjvmyKRGbLY52mA1KnxCo4 uNWRz8ixCTEjADbjWS/AS/B6i1uToacZwVzfA2zy/WrA0rZyvzf9IDzF8stQgybNF4YbUT9EzUQ F5ZUAMCIdS3gEwnAJZHDJEWJMssNtM/8l X-Gm-Gg: ASbGncsCGcReCEHg33FfIW6tF1ahGM0SIgEo6z7ToeSHtQecWo1qRRf6gT5kdPOfDV2 ScI5xfm2XUPKgPEbwMxfORdLqGi6eWh3XzVglcTmdmaU5X9d42XUSSMWRRY9fN7Zazxve78EVYm g= X-Google-Smtp-Source: AGHT+IHZI7rJxAKn5hk4y5mKt05fmnP3wilLfwAAjC8i9jF4MJfHKWu1Hr8JR55i19TK17HqKGylb8r60UbGP5zLGPY= X-Received: by 2002:a05:690c:4442:b0:6ef:4fba:8153 with SMTP id 00721157ae682-6f989eb4381mr64110987b3.10.1738846251161; Thu, 06 Feb 2025 04:50:51 -0800 (PST) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 6 Feb 2025 17:50:39 +0500 X-Gm-Features: AWEUYZnBaXIAMc8z_pQCLqhZAJydtLsVoVlikLCvDayy4MvrwonGZqMtEsmH5X8 Message-ID: Subject: Re: [PHP-DEV] RFC: Not Null Assertion Operator Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000001ea393062d78b195" From: 91liahim@gmail.com (Mihail Liahimov) --0000000000001ea393062d78b195 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for your answer. Now I will give examples for better understanding. Simple examples from Typescript: let foo =3D ... foo!.bar() foo!.someProperty.baz() Examples of potentially using in PHP: Without this operator we writing this code: $foo =3D ... if ($foo =3D=3D=3D null) { throw new FooIsNullException(); } $foo->bar. With this operator: $foo!->bar $foo!->someProperty->method(); $foo!->someProperty->anotherProperty!->method(); I think the postfix operator would be illogical in PHP because my operator is similar to the existing nullsafe operator in syntax. And it would be strange if its syntax were different. Or we can implement both operator syntaxes: prefix for accessing properties, and postfix for use with variables, as in your example. Nullsafe: $foo?->bar; Not null assertion: $foo!->bar; If variable bar would be null - php will throw an exception. But now i dont know which exception it would be :) This operator will be useful in cases where a null value in a specific place will violate the domain logic. Usually we write either assertions or checks and throw our exceptions for this. But it seems to me that the not null assertion operator will help avoid writing unnecessary code. The problem, of course, will be catching errors. It is not clear how to catch errors by a specific value. I will think about it. =D1=81=D1=80, 5 =D1=84=D0=B5=D0=B2=D1=80. 2025=E2=80=AF=D0=B3. =D0=B2 17:09= , Ilija Tovilo : > Hi Mihail > > Thanks for your proposal. > > On Wed, Feb 5, 2025 at 9:24=E2=80=AFAM Mihail Liahimov <91liahim@gmail.co= m> wrote: > > > > Good afternoon. I would like to create an RFC on the implementation of > the NOT null assertion operator. Do you think it makes sense to create it= ? > I was able to implement the operator. I've already posted a draft in my > github - > https://github.com/rekmixa/php-src/tree/feature/not_null_assertion_operat= or > > An example of the implementation of this operator can be viewed in > kotlin or in typescript. The point of it is that in places where we did n= ot > expect null, we should not make additional checks, but use this operator. > It will also be convenient for highlighting in the IDE. > > First off, it would be useful if you show some examples in your > proposals. Especially for people who don't know Kotlin, it's not clear > how such a feature would work. Looking at your patch, you're > introducing the !-> operator, which presumably would error on > (null)!->foo. A few thoughts: > > * This approach/patch seems unnecessarily limiting and complex. it > would be easier to create a postfix operator ! that works on all > expressions, and simply errors if null. This won't require much > special handling in the engine. It would also allow you to do > foo($bar!). TBH, this seems most useful for static analysis, but > assert($bar) will do there too, so I'm not particularly convinced we > need such a feature. > * Especially in the case of property access on null, it would be worth > considering whether we ever want to make this error by default, which > seems like the general trajectory PHP has been taking. This is > currently a warning (since PHP 8, and a notice since 5.0). If we rule > that out, the feature might make more sense. > > Ilija > --0000000000001ea393062d78b195 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thank you for your answer. = Now I will give examples for better
understanding.

Simple examples from Typescript:

le= t foo =3D ...
foo!.bar()
foo!.someProperty.baz()

= Examples of potentially using in PHP:
Without this operator we writing this cod= e:

$foo =3D ...

if ($foo =3D=3D=3D null) {
throw new FooIsNullException();
}

$foo->bar.

With= this operator:

$foo!->bar
$foo!->someP= roperty->method();
$foo!->someProperty->anotherProperty!->method();=

I think the postfix operator would be il= logical in PHP because my operator
is similar to the existing nullsafe operator= in syntax. And it would be
strange if its syntax were different.
Or we can impleme= nt both operator syntaxes: prefix for accessing
properties, and postfix for use= with variables, as in your example.

Null= safe:
$foo?->bar;
Not null assertion:
$foo!->bar;

If variable bar would be null - php will throw an exception. But now i d= ont
= know which exception it would be :)

This = operator will be useful in cases where a null value in a specific
place will v= iolate the domain logic. Usually we write either assertions or
checks and throw= our exceptions for this. But it seems to me that the not
null assertion operat= or will help avoid writing unnecessary code. The
problem, of course, will be ca= tching errors. It is not clear how to catch
errors by a specific value. I will = think about it.


=D1=81=D1=80, 5 =D1=84=D0=B5=D0=B2= =D1=80. 2025=E2=80=AF=D0=B3. =D0=B2 17:09, Ilija Tovilo <tovilo.ilija@gmail.com>:
Hi Mihail

Thanks for your proposal.

On Wed, Feb 5, 2025 at 9:24=E2=80=AFAM Mihail Liahimov <91liahim@gmail.com> wrote: >
> Good afternoon. I would like to create an RFC on the implementation of= the NOT null assertion operator. Do you think it makes sense to create it?= I was able to implement the operator. I've already posted a draft in m= y github - https://github= .com/rekmixa/php-src/tree/feature/not_null_assertion_operator
> An example of the implementation of this operator can be viewed in kot= lin or in typescript. The point of it is that in places where we did not ex= pect null, we should not make additional checks, but use this operator. It = will also be convenient for highlighting in the IDE.

First off, it would be useful if you show some examples in your
proposals. Especially for people who don't know Kotlin, it's not cl= ear
how such a feature would work. Looking at your patch, you're
introducing the !-> operator, which presumably would error on
(null)!->foo. A few thoughts:

* This approach/patch seems unnecessarily limiting and complex. it
would be easier to create a postfix operator ! that works on all
expressions, and simply errors if null. This won't require much
special handling in the engine. It would also allow you to do
foo($bar!). TBH, this seems most useful for static analysis, but
assert($bar) will do there too, so I'm not particularly convinced we need such a feature.
* Especially in the case of property access on null, it would be worth
considering whether we ever want to make this error by default, which
seems like the general trajectory PHP has been taking. This is
currently a warning (since PHP 8, and a notice since 5.0). If we rule
that out, the feature might make more sense.

Ilija
--0000000000001ea393062d78b195--