Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129508
Precedence: list
MIME-Version: 1.0
References: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
In-Reply-To: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
Date: Tue, 2 Dec 2025 14:28:07 +0200
Message-ID: <CAAwdEzDOd5v2UX4Ms8pn+73aSaVA1EMBr2n3c6RWztb5Fmanbg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Pattern Matching
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007903860644f73b7d"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000007903860644f73b7d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 1, 2025 at 11:39=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> Hi folks.  Ilija and I would like to present our latest RFC endeavor,
> pattern matching:
>
> https://wiki.php.net/rfc/pattern-matching
>
>
>
Great work, very detailed and well written.

1. There are mentions that any type present in a function parameter
signature and return value is a valid pattern matching.
But are there any plans to extend the pattern-matching-syntax to parameter
types and return values?
Of course, with some restrictions: without variable pinning.And without
variable binding on return type, but that could work on parameter types.
If that's possible or already planned, I think it's worth mentioning it in
the future scope section.

2. Maybe some parts of the RFC could be separated to reduce complexity.
Thinking about variable pinning.

3. For match() "is" placement, I would go with the second form as it's more
flexible, but I think allowing both forms might be nice if the complexity
is not too high.
Or go only with the second form now, and add the first form later in a
smaller RFC.


--=20
Alex

--0000000000007903860644f73b7d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote gmail=
_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Dec 1, 2025=
 at 11:39=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtec=
h.com">larry@garfieldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">Hi folks.=C2=A0 Ilija and I would like to pres=
ent our latest RFC endeavor, pattern matching:<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><br></blockquote><div><br></div><div>Great work, very detailed=C2=A0and=
 well written.</div><div><br></div><div>1. There are mentions that any type=
 present in a function parameter signature and return value is a valid patt=
ern matching.<br>But are there any plans to extend the pattern-matching-syn=
tax to parameter types and return values?<br>Of course, with some restricti=
ons: without variable pinning.And without variable binding on return type, =
but that could work on parameter types.</div><div>If that&#39;s possible or=
 already planned, I think it&#39;s worth mentioning it in the future scope=
=C2=A0section.</div><div><br></div><div>2. Maybe some parts of the RFC coul=
d be separated to reduce complexity.<br>Thinking about variable pinning.</d=
iv><div><br></div><div>3. For match() &quot;is&quot; placement, I would go =
with the second form as it&#39;s more flexible, but I think allowing both f=
orms might be nice if the complexity is not too high.</div><div>Or go only=
=C2=A0with the second form now, and add the first form later in a smaller R=
FC.</div><div><br></div><div><br></div><div>--=C2=A0</div><div>Alex</div><d=
iv><br></div></div></div>

--0000000000007903860644f73b7d--