Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123842
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: <c72033aa-7d55-4560-95ac-6c81c21cdc43@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LC49o=RVXigTrHte8EWSmwxPKqT4tyRGWpGf022PDCk8Q@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>
 <97a93ae2-5202-47eb-bf51-ec1e976ea765@app.fastmail.com>
 <CAPyj-LC49o=RVXigTrHte8EWSmwxPKqT4tyRGWpGf022PDCk8Q@mail.gmail.com>
Date: Tue, 25 Jun 2024 22:24:32 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Content-Type: multipart/alternative;
 boundary=dfb029247c304836a90178f1d881e6f5
From: rob@bottled.codes ("Rob Landers")

--dfb029247c304836a90178f1d881e6f5
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 25, 2024, at 20:23, Ilija Tovilo wrote:
> Hi Rob
>=20
> On Tue, Jun 25, 2024 at 9:05=E2=80=AFAM Rob Landers <rob@bottled.codes=
> wrote:
> >
> > 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.robe=
rt@gmail.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 d=
idn=E2=80=99t =E2=80=9Ctechnically=E2=80=9D fall, instead the Earth and =
them pulled at each other until they collided and the ground + body abso=
rbed the energy.
> >
> > While yes, you are =E2=80=9Ctechnically=E2=80=9D correct, what you d=
escribe is essentially unobservable from the context of the running code=
 (unless you turn the warning into an error/exception). For all direct a=
ccesses of array values ($arr['key']) an array is infinitely full of nul=
ls (I have actually depended on this property at one point for a bloom f=
ilter).
>=20
> If null array values were indeed unobservable, then [] would be =3D=3D=
=3D to
> [null] (or at least =3D=3D), and a foreach over [null] would result in=
 0
> iterations. But neither of those are the case.

I think there is a difference between an empty array and a null, and tha=
t is (hopefully) self-evident. I=E2=80=99m talking about the infinite nu=
lls IN the array. You can write a for loop of all possible keys until th=
e end of the universe, and all you will get is null. This is fairly easy=
 to prove. I'll wait... :p

>=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. A=
fter 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 sa=
me resulting code. If you can show a difference in the resulting code an=
d how it is an improvement, I may be inclined to agree, but I can=E2=80=99=
t think of one.
>=20
> 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.

The only way you=E2=80=99d observe this (that I can think of) is by perf=
orming a for-each loop over the array. In this case, I can't think of a =
reason you would assert the shape of individual keys beforehand. Maybe s=
omeone who would do that can chime in with a realistic example.

What I was talking about is something like this:

$hasFoo =3D $arr is [?'foo' =3D> string];

// if I understand the RFC correctly, $hasFoo is true for [] and ['foo' =
=3D> 'some-string']
if ( $hasFoo ) {
  $foobar =3D $arr['foo'] ?? null;
}

Now with the alternative:

$hasFoo =3D $arr is ['foo' =3D> ?string];

// in theory, this matches [], ['foo' =3D> null] and ['foo' =3D> 'some-s=
tring']
if ( $hasFoo ) {
  $foobar =3D $arr['foo'] ?? null;
}

Note that the actual code *did NOT* change. What we have is that in the =
first example, a person well-versed in PHP is going to wonder why `($has=
Foo is false) =3D=3D=3D true` and `($arr['foo'] is null) =3D=3D=3D true`=
. It's logically inconsistent with itself because we clearly specified t=
hat it shouldn't exist but it does exist and the value is NULL.

Yeah, it's weird that arrays are infinitely full of null, but surprising=
ly useful. If we don't like it, we can always create an RFC to treat non=
-existent keys as an error instead of a warning.
 =20

>=20
> Ilija
>=20

=E2=80=94 Rob
--dfb029247c304836a90178f1d881e6f5
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}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Tue, Ju=
n 25, 2024, at 20:23, Ilija Tovilo wrote:<br></div><blockquote type=3D"c=
ite" id=3D"qt" style=3D""><div>Hi Rob<br></div><div><br></div><div>On Tu=
e, Jun 25, 2024 at 9:05=E2=80=AFAM Rob Landers &lt;<a href=3D"mailto:rob=
@bottled.codes">rob@bottled.codes</a>&gt; wrote:<br></div><div>&gt;<br><=
/div><div>&gt; On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote:<br></=
div><div>&gt;<br></div><div>&gt; On Mon, Jun 24, 2024 at 9:54=E2=80=AFPM=
 Robert Landers &lt;<a href=3D"mailto:landers.robert@gmail.com">landers.=
robert@gmail.com</a>&gt; wrote:<br></div><div>&gt; &gt;<br></div><div>&g=
t; &gt; To be honest, this is one of the smaller concerns I have with th=
e new<br></div><div>&gt; &gt; syntax. There might be some misunderstandi=
ng here, though. A<br></div><div>&gt; &gt; non-existent key is NULL, alw=
ays has been, and always will be.<br></div><div>&gt;<br></div><div>&gt; =
This is just not accurate. Inexistent indexes are not null in PHP,<br></=
div><div>&gt; they are undefined. PHP implicitly coerces undefined to nu=
ll, because<br></div><div>&gt; undefined is not a value accessible to us=
ers. The same occurs when<br></div><div>&gt; accessing $undefinedVariabl=
e. For arrays, this fact is observable<br></div><div>&gt; through `forea=
ch`, warnings when accessing the index, and likely<br></div><div>&gt; ot=
hers.<br></div><div>&gt;<br></div><div>&gt; This is a bit like telling s=
omeone who fell off a ladder that they didn=E2=80=99t =E2=80=9Ctechnical=
ly=E2=80=9D fall, instead the Earth and them pulled at each other until =
they collided and the ground + body absorbed the energy.<br></div><div>&=
gt;<br></div><div>&gt; While yes, you are =E2=80=9Ctechnically=E2=80=9D =
correct, what you describe 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 inf=
initely full of nulls (I have actually depended on this property at one =
point for a bloom filter).<br></div><div><br></div><div>If null array va=
lues were indeed unobservable, then [] would be =3D=3D=3D to<br></div><d=
iv>[null] (or at least =3D=3D), and a foreach over [null] would result i=
n 0<br></div><div>iterations. But neither of those are the case.<br></di=
v></blockquote><div><br></div><div>I think there is a difference between=
 an empty array and a null, and that is (hopefully) self-evident. I=E2=80=
=99m talking about the infinite nulls IN the array. You can write a for =
loop of all possible keys until the end of the universe, and all you wil=
l get is null. This is fairly easy to prove. I'll wait... :p<br></div><d=
iv><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></d=
iv><div>&gt; So yes, `[?'foo' =3D&gt; string]` and `['foo' =3D&gt; ?stri=
ng]` are indeed<br></div><div>&gt; different. The former accepts `[]`, w=
hile the latter accepts `['foo'<br></div><div>&gt; =3D&gt; null]`.<br></=
div><div>&gt;<br></div><div>&gt; 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 resulting code. If you can show a differ=
ence in the resulting code and how it is an improvement, I may be inclin=
ed to agree, but I can=E2=80=99t think of one.<br></div><div><br></div><=
div>Sure. If a null value were to mean "not set", then ['foo' =3D&gt; st=
ring]<br></div><div>should accept ['foo' =3D&gt; 'foo', 'bar' =3D&gt; nu=
ll], which is absolutely<br></div><div>observable if the code assumes it=
 won't see any additional indexes.<br></div></blockquote><div><br></div>=
<div>The only way you=E2=80=99d observe this (that I can think of) is by=
 performing a for-each loop over the array. In this case, I can't think =
of a reason you would assert the shape of individual keys beforehand. Ma=
ybe someone who would do that can chime in with a realistic example.<br>=
</div><div><br></div><div>What I was talking about is something like thi=
s:<br></div><div><br></div><div>$hasFoo =3D $arr is [?'foo' =3D&gt; stri=
ng];<br></div><div><br></div><div>// if I understand the RFC correctly, =
$hasFoo is true for [] and ['foo' =3D&gt; 'some-string']</div><div>if ( =
$hasFoo ) {<br></div><div>&nbsp; $foobar =3D $arr['foo'] ?? null;<br></d=
iv><div>}<br></div><div><br></div><div>Now with the alternative:<br></di=
v><div><br></div><div>$hasFoo =3D $arr is ['foo' =3D&gt; ?string];<br></=
div><div><br></div><div>// in theory, this matches [], ['foo' =3D&gt; nu=
ll] and ['foo' =3D&gt; 'some-string']<br></div><div>if ( $hasFoo ) {<br>=
</div><div>&nbsp; $foobar =3D $arr['foo'] ?? null;<br></div><div>}<br></=
div><div><br></div><div>Note that the actual code&nbsp;<i>did NOT</i> ch=
ange. What we have is that in the first example, a person well-versed in=
 PHP is going to wonder why `($hasFoo is false) =3D=3D=3D true` and `($a=
rr['foo'] is null) =3D=3D=3D true`. It's logically inconsistent with its=
elf because we clearly specified that it shouldn't exist but it does exi=
st and the value is NULL.<br></div><div><br></div><div>Yeah, it's weird =
that arrays are infinitely full of null, but surprisingly useful. If we =
don't like it, we can always create an RFC to treat non-existent keys as=
 an error instead of a warning.</div><div>&nbsp;&nbsp;</div><div><br></d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>Il=
ija<br></div><div><br></div></blockquote><div><br></div><div id=3D"sig12=
1229152">=E2=80=94 Rob<br></div></body></html>
--dfb029247c304836a90178f1d881e6f5--