Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123837
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>
 <CAPyj-LAM7yPZpcArjHYEG8HhNRR-hA8sgzAjXT7Wf8X4mVgmQA@mail.gmail.com> <97a93ae2-5202-47eb-bf51-ec1e976ea765@app.fastmail.com>
In-Reply-To: <97a93ae2-5202-47eb-bf51-ec1e976ea765@app.fastmail.com>
Date: Tue, 25 Jun 2024 20:23:01 +0200
Message-ID: <CAPyj-LC49o=RVXigTrHte8EWSmwxPKqT4tyRGWpGf022PDCk8Q@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)

Hi Rob

On Tue, Jun 25, 2024 at 9:05=E2=80=AFAM Rob Landers <rob@bottled.codes> wro=
te:
>
> On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote:
>
> On Mon, Jun 24, 2024 at 9:54=E2=80=AFPM Robert Landers <landers.robert@gm=
ail.com> wrote:
> >
> > 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.
>
> This is a bit like telling someone who fell off a ladder that they didn=
=E2=80=99t =E2=80=9Ctechnically=E2=80=9D fall, instead the Earth and them p=
ulled at each other until they collided and the ground + body absorbed the =
energy.
>
> While yes, you are =E2=80=9Ctechnically=E2=80=9D correct, what you descri=
be is essentially unobservable from the context of the running code (unless=
 you turn the warning into an error/exception). For all direct accesses of =
array values ($arr['key']) an array is infinitely full of nulls (I have act=
ually depended on this property at one point for a bloom filter).

If null array values were indeed unobservable, then [] would be =3D=3D=3D t=
o
[null] (or at least =3D=3D), and a foreach over [null] would result in 0
iterations. But neither of those are the case.

> So yes, `[?'foo' =3D> string]` and `['foo' =3D> ?string]` are indeed
> different. The former accepts `[]`, while the latter accepts `['foo'
> =3D> null]`.
>
> Are they actually different in practice though? That was my point. After =
the =E2=80=9Cis=E2=80=9D in both cases, you=E2=80=99ll have to use null-coa=
lescence to retrieve the value. For all intents, they are the same resultin=
g code. If you can show a difference in the resulting code and how it is an=
 improvement, I may be inclined to agree, but I can=E2=80=99t think of one.

Sure. If a null value were to mean "not set", then ['foo' =3D> string]
should accept ['foo' =3D> 'foo', 'bar' =3D> null], which is absolutely
observable if the code assumes it won't see any additional indexes.

Ilija