Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123709
Precedence: bulk
MIME-Version: 1.0
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
In-Reply-To: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
Date: Thu, 20 Jun 2024 22:22:19 +0200
Message-ID: <CANS-=pec_6nSNFRvVObxGw2iKXRpJvMaydUt6N5UkZUdi6qu3Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000c86f4061b581448"
From: kjarli@gmail.com (Lynn)

--0000000000000c86f4061b581448
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 20, 2024 at 7:41=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> Hello, peoples.
>
> Ilija and I have been working on and off on an RFC for pattern matching
> since the early work on Enumerations.  A number of people have noticed an=
d
> said they're looking forward to it.
>
> It's definitely not going to make it into 8.4, but we are looking for
> early feedback on scoping the RFC.  In short, there's a whole bunch of
> possible patterns that could be implemented, and some of them we already
> have, but we want to get a sense of what scope the zeitgeist would want i=
n
> the "initial" RFC, which would be appropriate as secondary votes, and whi=
ch
> we should explicitly save-for-later.  The goal is to not spend time on
> particular patterns that will be contentious or not pass, and focus effor=
t
> on fleshing out and polishing those that do have a decent consensus.  (An=
d
> thereby, we hope, avoiding an RFC failing because enough people dislike o=
ne
> little part of it.)
>
> To that end, we're looking for *very high level* feedback on this RFC:
>
> https://wiki.php.net/rfc/pattern-matching
>
> By "very high level," I mean, please, do not sweat specific syntax detail=
s
> right now.  That's a distraction.  What we're asking right now is "which =
of
> these patterns should we spend time sweating specific syntax details on i=
n
> the coming weeks/months?"  There will be ample time for detail bikesheddi=
ng
> later, and we've identified a couple of areas where we know for certain
> further syntax development will be needed because we both hate the curren=
t
> syntax. :-)
>
> If you want to just read the Overview section for a survey of the possibl=
e
> patterns and our current recommendations, you likely don't need to read t=
he
> rest of the RFC at this point.  You can if you want, but again, please st=
ay
> high-level.  Our goal at the moment is to get enough feedback to organize
> the different options into three groups:
>
> 1. Part of the RFC.
> 2. Secondary votes in the RFC.
> 3. Future Scope.
>
> So we know where to focus our efforts to bring it to a proper discussion.
>
> Thank you all for your participation.
>
> --
>   Larry Garfield
>   larry@garfieldtech.com


I have been looking forward to this RFC, it's such a quality of life to be
able to do all this! In terms of things to focus on, I'd personally be very
happy with the property/param guards, "as" and "is <regex>", but I won't
say no to anything we can get extra here because it's all really nice to
have.

I noticed that with array structure patterns the count is omitted when
using ...
```php
if ($list is [1, 3, ...]) {
  print "Yes";
}
// True.  Equivalent to:
if (is_array($list)
    && array_key_exists(0, $list) && $list[0] =3D=3D=3D 1
    && array_key_exists(1, $list) && $list[1] =3D=3D=3D 3
    ) {
    print "Yes";
}
```
Wouldn't this need a `count($list) >=3D 2`? I'm not sure if the
underlying mechanism does the count check as well, but it seems to me like
a guard clause for performance reasons in the PHP variant. Maybe a tangent,
what about iterators?

"Limited expression pattern"
I think this would be very valuable to have, though in the proposal it
seems cumbersome to use regardless of syntax. It feels like I'm going to be
using the variable binding less often than matching against other
variables, what about an "out" equivalent?

```php
$result =3D match ($p) is {
  Point{x: 3, y: 9, $z} =3D> "x is 3, y is 9, z is $z",
  Point{$x, $y, $z} =3D> "x is $x, y is $y, z is $z",
};
// vs
$x =3D 3;
$y =3D 9;
$result =3D match ($p) is {
  Point{x: 3, y: 9, out $z} =3D> "x is 3, y is 9, z is $z",
  Point{$x, $y, out $z} =3D> "x is 3, y is 9, z is $z",
};
```
To me this makes it much more readable, just not sure if this is even
feasible. This is not meant as bikeshedding the syntax, more of an
alternative approach to when to use which.

--0000000000000c86f4061b581448
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 20, 2024 at 7:41=E2=80=AF=
PM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfi=
eldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Hello, peoples.<br>
<br>
Ilija and I have been working on and off on an RFC for pattern matching sin=
ce the early work on Enumerations.=C2=A0 A number of people have noticed an=
d said they&#39;re looking forward to it.<br>
<br>
It&#39;s definitely not going to make it into 8.4, but we are looking for e=
arly feedback on scoping the RFC.=C2=A0 In short, there&#39;s a whole bunch=
 of possible patterns that could be implemented, and some of them we alread=
y have, but we want to get a sense of what scope the zeitgeist would want i=
n the &quot;initial&quot; RFC, which would be appropriate as secondary vote=
s, and which we should explicitly save-for-later.=C2=A0 The goal is to not =
spend time on particular patterns that will be contentious or not pass, and=
 focus effort on fleshing out and polishing those that do have a decent con=
sensus.=C2=A0 (And thereby, we hope, avoiding an RFC failing because enough=
 people dislike one little part of it.)<br>
<br>
To that end, we&#39;re looking for *very high level* feedback on this RFC:<=
br>
<br>
<a href=3D"https://wiki.php.net/rfc/pattern-matching" rel=3D"noreferrer" ta=
rget=3D"_blank">https://wiki.php.net/rfc/pattern-matching</a><br>
<br>
By &quot;very high level,&quot; I mean, please, do not sweat specific synta=
x details right now.=C2=A0 That&#39;s a distraction.=C2=A0 What we&#39;re a=
sking right now is &quot;which of these patterns should we spend time sweat=
ing specific syntax details on in the coming weeks/months?&quot;=C2=A0 Ther=
e will be ample time for detail bikeshedding later, and we&#39;ve identifie=
d a couple of areas where we know for certain further syntax development wi=
ll be needed because we both hate the current syntax. :-)<br>
<br>
If you want to just read the Overview section for a survey of the possible =
patterns and our current recommendations, you likely don&#39;t need to read=
 the rest of the RFC at this point.=C2=A0 You can if you want, but again, p=
lease stay high-level.=C2=A0 Our goal at the moment is to get enough feedba=
ck to organize the different options into three groups:<br>
<br>
1. Part of the RFC.<br>
2. Secondary votes in the RFC.<br>
3. Future Scope.<br>
<br>
So we know where to focus our efforts to bring it to a proper discussion.<b=
r>
<br>
Thank you all for your participation.<br>
<br>
-- <br>
=C2=A0 Larry Garfield<br>
=C2=A0 <a href=3D"mailto:larry@garfieldtech.com" target=3D"_blank">larry@ga=
rfieldtech.com</a></blockquote><div><br></div><div>I have been looking forw=
ard to this RFC, it&#39;s such a quality of life to be able to do all this!=
 In terms of things to focus on, I&#39;d personally be very happy with the =
property/param guards, &quot;as&quot; and &quot;is &lt;regex&gt;&quot;, but=
 I won&#39;t say no to anything we can get extra here because it&#39;s all =
really nice to have.</div><div><br></div><div>I noticed that with array str=
ucture patterns the count is omitted when using ...<br>```php</div><div>if =
($list is [1, 3, ...]) {<br>=C2=A0 print &quot;Yes&quot;;<br>}<br>// True.=
=C2=A0 Equivalent to:<br>if (is_array($list) <br>=C2=A0 =C2=A0 &amp;&amp; a=
rray_key_exists(0, $list) &amp;&amp; $list[0] =3D=3D=3D 1 <br>=C2=A0 =C2=A0=
 &amp;&amp; array_key_exists(1, $list) &amp;&amp; $list[1] =3D=3D=3D 3<br>=
=C2=A0 =C2=A0 ) {<br>=C2=A0 =C2=A0 print &quot;Yes&quot;;<br>}<br>```</div>=
<div>Wouldn&#39;t this need a `count($list) &gt;=3D 2`? I&#39;m not sure if=
 the underlying=C2=A0mechanism does the count check as well, but it seems t=
o me like a guard clause for performance reasons in the PHP variant. Maybe =
a tangent, what about iterators?</div><div><br></div><div>&quot;Limited exp=
ression pattern&quot;</div><div>I think this would be very valuable to have=
, though in the proposal it seems cumbersome to use regardless of syntax. I=
t feels like I&#39;m going to be using the variable binding less often than=
 matching against other variables, what about an &quot;out&quot; equivalent=
?</div><div><br></div><div>```php<br>$result =3D match ($p) is {<br>=C2=A0 =
Point{x: 3, y: 9, $z} =3D&gt; &quot;x is 3, y is 9, z is $z&quot;,<br>=C2=
=A0 Point{$x, $y, $z} =3D&gt; &quot;x is $x, y is $y, z is $z&quot;,<br>};<=
/div><div>// vs</div><div>$x =3D 3;</div><div>$y =3D 9;</div><div>$result =
=3D match ($p) is {<br>=C2=A0 Point{x: 3, y: 9, out $z} =3D&gt; &quot;x is =
3, y is 9, z is $z&quot;,<br>=C2=A0 Point{$x, $y, out $z} =3D&gt; &quot;x i=
s 3, y is 9, z is $z&quot;,<br>};<br>```</div><div>To me this makes it much=
 more readable, just not sure if this is even feasible. This is not meant a=
s bikeshedding the syntax, more of an alternative approach to when to use w=
hich.</div><div><br></div><div><br></div><div><br></div></div></div>

--0000000000000c86f4061b581448--