Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:123873 php.internals:123874
Message-ID: <0F7B09EC-C38E-4B49-9137-1FB3EA5231AC@miles.systems>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B80798C1-7878-4DF8-A259-B417E21793A6"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Date: Wed, 26 Jun 2024 11:57:22 -0600
In-Reply-To: <d06e5a04-9601-4af4-bdad-4f5e92bc5e18@app.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <d06e5a04-9601-4af4-bdad-4f5e92bc5e18@app.fastmail.com>
From: richard@miles.systems (Richard Miles)


--Apple-Mail=_B80798C1-7878-4DF8-A259-B417E21793A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

=E2=80=9CArray-application will also be pushed to future-scope=E2=80=9D


Dang, this is what I was looking forward to the most. Helping set some =
precedent on this issue, and this is a solid start. I=E2=80=99ve been =
thinking about what it would look like for strictly typed arrays in PHP =
for a while now. I think a custom implantation like SqlObjectStorage or =
SplFixedArray could help performance since we now have a fixed list and =
no need for a hash table, and it may solve some complexity in =
implementation. This is slightly off-topic, but if anyone is interested =
in working on a typed arrays initiative, please contact me directly.=20


That said, I agree with Robert Landers, who wrote the following:

There's no need to use `?` to check for existence on a key, so this:

$arr is ['a' =3D> string, ?'b' =3D> string, ...];

should be this:

$arr is ['a' =3D> string, 'b' =3D> ?string, =E2=80=A6];

______

Chuck Adams cleared that up with:
The first means b is an optional key, but if it=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.
______

I think there is a need to ensure a key does not exist even if we=E2=80=99=
re not happy about this syntax, but if not having `$arr is ['a' =3D> =
string, 'b' =3D> ?string, =E2=80=A6]` would still make me very happy.=20

Best,

Richard Miles


> On Jun 24, 2024, at 5:31=E2=80=AFPM, Larry Garfield =
<larry@garfieldtech.com> wrote:
>=20
> On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:
>=20
>> To that end, we're looking for *very high level* feedback on this =
RFC:
>>=20
>> https://wiki.php.net/rfc/pattern-matching
>=20
> Hi folks.  Thank you to those who have offered feedback so far.  Based =
on the discussion, here's what we're thinking of doing (still subject to =
change, of course):
>=20
> * We're going to move `as` to future-scope.  There's enough weirdness =
around it that is independent of pattern matching itself that it will =
likely require its own discussion and RFC, and may or may not involve =
full pattern support.
>=20
> * Similarly, we're going to hold off on the weak-mode flag.  It sounds =
like the language needs to do more to fix the definition of "weak mode" =
before it's really viable. :-(  On the plus side, if the type system =
itself ever adds support for a "coercion permitted" flag, patterns =
should inherit that naturally, I think.
>=20
> * Array-application will also be pushed to future-scope.  Again, =
there's enough type-system tie in here that is tangential to patterns =
that we'll pick that fight later.
>=20
> * Ilija and I have discussed regex patterns a bit further, and it =
sounds like they=E2=80=99re going to be rather complicated to implement. =
 Even assuming we agree on the syntax for it, it would be a substantial =
amount of code to support.  (It=E2=80=99s not like types or literals or =
range where we can just drop something pre-existing into a new =
function.)  So we=E2=80=99re going to hold off on this one for now, =
though it does seem like a high-priority follow-up for the future.  =
(Which doesn=E2=80=99t have to be us!)
>=20
> So let's not discuss the above items further at this point.
>=20
> * I'm going to do some additional research into other languages to see =
how they handle binding vs using variables from scope, and what syntax =
markers they use and where.  Once we have a better sense of what is out =
there and is known to work, we can make a more informed plan for what we =
should do in PHP.  (Whether using a variable from scope in the pattern =
is part of the initial RFC is still an open question, but we do need to =
design it alongside the capture part to ensure they don't conflict.)  =
Stay tuned on this front.
>=20
> * We've removed the dedicated wildcard pattern, as it's equivalent to =
`mixed`.  If there's interest, we're open to having a secondary vote to =
bring it back as a short-hand pattern.  It's trivial to implement and we =
don't have strong feelings either way.
>=20
> * There's not been much discussion of range patterns.  Anyone want to =
weigh in on those?
>=20
> * The placement of `is` on `match()` is still an open question.
>=20
> * No one has really weighed in on nested patterns for captured =
variables.  Any thoughts there?
>=20
> * I=E2=80=99ve seen a suggestion for capturing the =E2=80=9Crest=E2=80=9D=
 of an array when using =E2=80=A6  That=E2=80=99s an interesting idea, =
and we=E2=80=99ll explore it, though it looks like it may have some =
interesting implications that push it to future scope.  It feels like a =
nice-to-have.
>=20
> Thanks all.
>=20
> --Larry Garfield


--Apple-Mail=_B80798C1-7878-4DF8-A259-B417E21793A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: =
after-white-space;">=E2=80=9CArray-application will also be pushed to =
future-scope=E2=80=9D<div><br><div><br></div><div>Dang, this is what I =
was looking forward to the most. Helping set some precedent on this =
issue, and this is a solid start. I=E2=80=99ve been thinking about what =
it would look like for strictly typed arrays in PHP for a while now. I =
think a custom implantation like SqlObjectStorage or SplFixedArray could =
help performance since we now have a fixed list and no need for a hash =
table, and it may solve some complexity in implementation. This is =
slightly off-topic, but if anyone is interested in working on a typed =
arrays initiative, please contact me =
directly.&nbsp;</div><div><br></div><div><br></div><div>That said, I =
agree with Robert Landers, who wrote the =
following:</div><div><br></div><div>There's no need to use `?` to check =
for existence on a key, so this:<br><br>$arr is ['a' =3D&gt; string, =
?'b' =3D&gt; string, ...];<br><br>should be this:<br><br>$arr is ['a' =
=3D&gt; string, 'b' =3D&gt; ?string, =
=E2=80=A6];</div><div><br></div><div>______</div><div><br></div><div>Chuck=
 Adams cleared that up with:</div><div>The first means b is an optional =
key, but if it=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.</div><div>______</div><div><br></div><div>I think =
there is a need to ensure a key does not exist even if we=E2=80=99re not =
happy about this syntax, but if not having `$arr is ['a' =3D&gt; string, =
'b' =3D&gt; ?string, =E2=80=A6]` would still make me very =
happy.&nbsp;</div><div><br><div>
<div dir=3D"auto" style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: 400; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); overflow-wrap: =
break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;"><div>Best,</div><div><br></div><div>Richard =
Miles</div></div><div style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: 400; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div>
</div>
<div><br><blockquote type=3D"cite"><div>On Jun 24, 2024, at 5:31=E2=80=AFP=
M, Larry Garfield &lt;larry@garfieldtech.com&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>On Thu, Jun 20, 2024, at =
5:38 PM, Larry Garfield wrote:<br><br><blockquote type=3D"cite">To that =
end, we're looking for *very high level* feedback on this =
RFC:<br><br>https://wiki.php.net/rfc/pattern-matching<br></blockquote><br>=
Hi folks. &nbsp;Thank you to those who have offered feedback so far. =
&nbsp;Based on the discussion, here's what we're thinking of doing =
(still subject to change, of course):<br><br>* We're going to move `as` =
to future-scope. &nbsp;There's enough weirdness around it that is =
independent of pattern matching itself that it will likely require its =
own discussion and RFC, and may or may not involve full pattern =
support.<br><br>* Similarly, we're going to hold off on the weak-mode =
flag. &nbsp;It sounds like the language needs to do more to fix the =
definition of "weak mode" before it's really viable. :-( &nbsp;On the =
plus side, if the type system itself ever adds support for a "coercion =
permitted" flag, patterns should inherit that naturally, I =
think.<br><br>* Array-application will also be pushed to future-scope. =
&nbsp;Again, there's enough type-system tie in here that is tangential =
to patterns that we'll pick that fight later.<br><br>* Ilija and I have =
discussed regex patterns a bit further, and it sounds like they=E2=80=99re=
 going to be rather complicated to implement. &nbsp;Even assuming we =
agree on the syntax for it, it would be a substantial amount of code to =
support. &nbsp;(It=E2=80=99s not like types or literals or range where =
we can just drop something pre-existing into a new function.) &nbsp;So =
we=E2=80=99re going to hold off on this one for now, though it does seem =
like a high-priority follow-up for the future. &nbsp;(Which doesn=E2=80=99=
t have to be us!)<br><br>So let's not discuss the above items further at =
this point.<br><br>* I'm going to do some additional research into other =
languages to see how they handle binding vs using variables from scope, =
and what syntax markers they use and where. &nbsp;Once we have a better =
sense of what is out there and is known to work, we can make a more =
informed plan for what we should do in PHP. &nbsp;(Whether using a =
variable from scope in the pattern is part of the initial RFC is still =
an open question, but we do need to design it alongside the capture part =
to ensure they don't conflict.) &nbsp;Stay tuned on this front.<br><br>* =
We've removed the dedicated wildcard pattern, as it's equivalent to =
`mixed`. &nbsp;If there's interest, we're open to having a secondary =
vote to bring it back as a short-hand pattern. &nbsp;It's trivial to =
implement and we don't have strong feelings either way.<br><br>* There's =
not been much discussion of range patterns. &nbsp;Anyone want to weigh =
in on those?<br><br>* The placement of `is` on `match()` is still an =
open question.<br><br>* No one has really weighed in on nested patterns =
for captured variables. &nbsp;Any thoughts there?<br><br>* I=E2=80=99ve =
seen a suggestion for capturing the =E2=80=9Crest=E2=80=9D of an array =
when using =E2=80=A6 &nbsp;That=E2=80=99s an interesting idea, and =
we=E2=80=99ll explore it, though it looks like it may have some =
interesting implications that push it to future scope. &nbsp;It feels =
like a nice-to-have.<br><br>Thanks all.<br><br>--Larry =
Garfield<br></div></div></blockquote></div><br></div></div></body></html>=

--Apple-Mail=_B80798C1-7878-4DF8-A259-B417E21793A6--