Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123795
Precedence: bulk
MIME-Version: 1.0
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <CAG4FTXz6cH26C5H51VmTGnpFK5XxROFbW4yDzwAw2v1gcQWGgA@mail.gmail.com>
 <CAPzBOBOTSCCKDR4pDocr4xW+oEXJ27YizgPLkn1PGR9nyPU7ww@mail.gmail.com>
 <1E295280-619B-4490-B53C-0899B64F9215@chaz.works> <CAPzBOBPSSEmEbPj1zLcfGOOG7voo7YMUO16NjXzpTy7Wfx4ycw@mail.gmail.com>
In-Reply-To: <CAPzBOBPSSEmEbPj1zLcfGOOG7voo7YMUO16NjXzpTy7Wfx4ycw@mail.gmail.com>
Date: Tue, 25 Jun 2024 01:20:50 +0200
Message-ID: <CAPyj-LAM7yPZpcArjHYEG8HhNRR-hA8sgzAjXT7Wf8X4mVgmQA@mail.gmail.com>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
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)

On Mon, Jun 24, 2024 at 9:54=E2=80=AFPM Robert Landers <landers.robert@gmai=
l.com> wrote:
>
> > The first means b is an optional key, but if it=E2=80=99s there, can on=
ly be a string. The second says b is a required key, but it may be a string=
 or null. If there were a binding involved, that determines the type of the=
 binding in incompatible ways.  I=E2=80=99m fine with requiring bindings to=
 be nullable for optional keys, but it strikes me as strictly less flexible=
 and not consistent with the rest of PHP=E2=80=99s behavior, at least not u=
nder E_ALL.
> >
>
> To be honest, this is one of the smaller concerns I have with the new
> syntax. There might be some misunderstanding here, though. A
> non-existent key is NULL, always has been, and always will be.

This is just not accurate. Inexistent indexes are not null in PHP,
they are undefined. PHP implicitly coerces undefined to null, because
undefined is not a value accessible to users. The same occurs when
accessing $undefinedVariable. For arrays, this fact is observable
through `foreach`, warnings when accessing the index, and likely
others.

So yes, `[?'foo' =3D> string]` and `['foo' =3D> ?string]` are indeed
different. The former accepts `[]`, while the latter accepts `['foo'
=3D> null]`.

> $arr =3D ['a' =3D> 'a string'];
> $arr is ['a' =3D> string, ?'b' =3D> $value, ...];
>
> This syntax implies that a non-existent key is a special case, and if
> it passes as-is, it will be. If there is a binding and the key is
> missing, what happens to that binding?

This is the same problem as `|`. Variable bindings within optional
keys must be forbidden. I already mentioned that to Larry when we
thought about this idea.

Ilija