Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123804
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <97a93ae2-5202-47eb-bf51-ec1e976ea765@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LAM7yPZpcArjHYEG8HhNRR-hA8sgzAjXT7Wf8X4mVgmQA@mail.gmail.com>
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>
Date: Tue, 25 Jun 2024 09:04:52 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Content-Type: multipart/alternative;
 boundary=0ff1c73b33a6427cac8250774db897ca
From: rob@bottled.codes ("Rob Landers")

--0ff1c73b33a6427cac8250774db897ca
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable



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=
@gmail.com> wrote:
> >
> > > The first means b is an optional key, but if it=E2=80=99s there, c=
an only 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 requiri=
ng bindings to be nullable for optional keys, but it strikes me as stric=
tly less flexible and not consistent with the rest of PHP=E2=80=99s beha=
vior, at least not under 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.
>=20
> 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 t=
he energy.

While yes, you are =E2=80=9Ctechnically=E2=80=9D correct, what you descr=
ibe is essentially unobservable from the context of the running code (un=
less you turn the warning into an error/exception). For all direct acces=
ses of array values ($arr['key']) an array is infinitely full of nulls (=
I have actually depended on this property at one point for a bloom filte=
r).

>=20
> 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=
-coalescence to retrieve the value. For all intents, they are the same r=
esulting code. If you can show a difference in the resulting code and ho=
w it is an improvement, I may be inclined to agree, but I can=E2=80=99t =
think of one.=20

> > $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?
>=20
> 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.
>=20
> Ilija
>=20

=E2=80=94 Rob
--0ff1c73b33a6427cac8250774db897ca
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote:<br></=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On Mon, Jun 24, =
2024 at 9:54=E2=80=AFPM Robert Landers &lt;<a href=3D"mailto:landers.rob=
ert@gmail.com">landers.robert@gmail.com</a>&gt; wrote:<br></div><div>&gt=
;<br></div><div>&gt; &gt; The first means b is an optional key, but if i=
t=E2=80=99s there, can only 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.&nbsp; I=E2=
=80=99m fine with requiring bindings to be nullable for optional keys, b=
ut it strikes me as strictly less flexible and not consistent with the r=
est of PHP=E2=80=99s behavior, at least not under E_ALL.<br></div><div>&=
gt; &gt;<br></div><div>&gt;<br></div><div>&gt; To be honest, this is one=
 of the smaller concerns I have with the new<br></div><div>&gt; syntax. =
There might be some misunderstanding here, though. A<br></div><div>&gt; =
non-existent key is NULL, always has been, and always will be.<br></div>=
<div><br></div><div>This is just not accurate. Inexistent indexes are no=
t null in PHP,<br></div><div>they are undefined. PHP implicitly coerces =
undefined to null, because<br></div><div>undefined is not a value access=
ible to users. The same occurs when<br></div><div>accessing $undefinedVa=
riable. For arrays, this fact is observable<br></div><div>through `forea=
ch`, warnings when accessing the index, and likely<br></div><div>others.=
<br></div></blockquote><div><br></div><div>This is a bit like telling so=
meone who fell off a ladder that they didn=E2=80=99t =E2=80=9Ctechnicall=
y=E2=80=9D fall, instead the Earth and them pulled at each other until t=
hey collided and the ground + body absorbed the energy.<br></div><div><b=
r></div><div>While yes, you are =E2=80=9Ctechnically=E2=80=9D correct, w=
hat you describe is essentially unobservable from the context of the run=
ning code (unless you turn the warning into an error/exception). For all=
 direct accesses of array values ($arr['key']) an array is infinitely fu=
ll of nulls (I have actually depended on this property at one point for =
a bloom filter).<br></div><div><br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div><br></div><div>So yes, `[?'foo' =3D&gt; string]` an=
d `['foo' =3D&gt; ?string]` are indeed<br></div><div>different. The form=
er accepts `[]`, while the latter accepts `['foo'<br></div><div>=3D&gt; =
null]`.<br></div></blockquote><div><br></div><div>Are they actually diff=
erent 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-coalescence to retrie=
ve the value. For all intents, they are the same resulting 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.&nbsp;</d=
iv><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&g=
t; $arr =3D ['a' =3D&gt; 'a string'];<br></div><div>&gt; $arr is ['a' =3D=
&gt; string, ?'b' =3D&gt; $value, ...];<br></div><div>&gt;<br></div><div=
>&gt; This syntax implies that a non-existent key is a special case, and=
 if<br></div><div>&gt; it passes as-is, it will be. If there is a bindin=
g and the key is<br></div><div>&gt; missing, what happens to that bindin=
g?<br></div><div><br></div><div>This is the same problem as `|`. Variabl=
e bindings within optional<br></div><div>keys must be forbidden. I alrea=
dy mentioned that to Larry when we<br></div><div>thought about this idea=
.<br></div><div><br></div><div>Ilija<br></div><div><br></div></blockquot=
e><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body>=
</html>
--0ff1c73b33a6427cac8250774db897ca--