Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126309
Precedence: bulk
MIME-Version: 1.0
References: <CAJWOiuN7uO_gYhqcwD7UPC=z8VC_A_f1-yAoddBVAt-+p9ZCgA@mail.gmail.com>
 <CAPyj-LAnSfcPd8Qgix+crNY3QpTrwj5U2k-7ruH7LU8UZqQE7Q@mail.gmail.com> <CAJWOiuMzd81COK8weOeAudOB2B_2J3JOZGAMtAGYjvy8r69hUQ@mail.gmail.com>
In-Reply-To: <CAJWOiuMzd81COK8weOeAudOB2B_2J3JOZGAMtAGYjvy8r69hUQ@mail.gmail.com>
Date: Thu, 6 Feb 2025 15:48:18 +0100
Message-ID: <CAPyj-LBH5YW-bQwhx5HPmAj9y5z+DAPoiWE5GBZ6yeCQbLSeiQ@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Not Null Assertion Operator
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Mihail

On Thu, Feb 6, 2025 at 1:51=E2=80=AFPM Mihail Liahimov <91liahim@gmail.com>=
 wrote:
>
> Examples of potentially using in PHP:
> Without this operator we writing this code:
>
> $foo!->bar
> $foo!->someProperty->method();
> $foo!->someProperty->anotherProperty!->method();
>
> I think the postfix operator would be illogical in PHP because my operato=
r
> 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;

With a postfix operator this would all work automatically, assuming
that $foo!->bar can be parsed correctly as ($foo!)->bar. The, $foo!
will check that $foo is not null, and if not, access the property bar
on it.

> 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 o=
r
> 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.

I think, if such an operator were introduced, it should throw an Error
rather than an Exception. Errors should generally not be caught, as
they indicate logical errors in your program.

There are two things to consider:

* Is assert($foo !=3D=3D null); $foo->bar; really much worse? I understand
it requires two statements, so it cannot be used in all contexts.
* Are we ever going to promote the (null)->prop warning to an Error?
If so, is there still any appeal for this feature? E.g. it would
automatically work on array access ($array!['foo']). Array access on
null may be more controversial to promote to an Error. There are some
other potential contexts, like foo($bar!), but you could argue this is
already covered by parameter types.

Ilija