Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129522
Precedence: list
MIME-Version: 1.0
References: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
 <CAAwdEzDOd5v2UX4Ms8pn+73aSaVA1EMBr2n3c6RWztb5Fmanbg@mail.gmail.com> <cef355bf-8066-4b06-a999-f313fbae5474@app.fastmail.com>
In-Reply-To: <cef355bf-8066-4b06-a999-f313fbae5474@app.fastmail.com>
Date: Wed, 3 Dec 2025 10:21:29 +0200
Message-ID: <CAAwdEzBx98AYsERFF+wkwGxagN5O5gd_9T09RBh_KGH4KPSx_g@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="000000000000416735064507e791"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000416735064507e791
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 2, 2025 at 10:09=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

>
>
> > 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.
>
> See the linked "speculative extensions" document.  It's mentioned there,
> but it hasn't gone beyond "Larry thinks it would be kinda cool to write
> `public int $x is >0`.  That's definitely out of scope for now, but I'm
> very open to discussing it in the future.
>


That is not exactly what I meant.
Since all types are valid patterns, can't we enlarge the type set to
include more things from the pattern set? in future RFCs.
Something like this: `function process(Point(x: 3|4, y: $y) $p): ['a' =3D>
int, 'b' =3D> float & >0]`.

--=20
Alex

--000000000000416735064507e791
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 g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec 2, =
2025 at 10:09=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfiel=
dtech.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 rg=
b(204,204,204);padding-left:1ex"><br>
<br>
&gt; 1. There are mentions that any type present in a function parameter <b=
r>
&gt; signature and return value is a valid pattern matching.<br>
&gt; But are there any plans to extend the pattern-matching-syntax to <br>
&gt; parameter types and return values?<br>
&gt;<br>
&gt; Of course, with some restrictions: without variable pinning.And withou=
t <br>
&gt; variable binding on return type, but that could work on parameter type=
s.<br>
&gt; If that&#39;s possible or already planned, I think it&#39;s worth ment=
ioning it <br>
&gt; in the future scope section.<br>
<br>
See the linked &quot;speculative extensions&quot; document.=C2=A0 It&#39;s =
mentioned there, but it hasn&#39;t gone beyond &quot;Larry thinks it would =
be kinda cool to write `public int $x is &gt;0`.=C2=A0 That&#39;s definitel=
y out of scope for now, but I&#39;m very open to discussing it in the futur=
e.<br>=C2=A0</blockquote><div><br></div><div>That is not exactly what I mea=
nt.</div><div>Since all types are valid patterns, can&#39;t we enlarge the =
type set to include more things from the pattern set? in future RFCs.</div>=
<div>Something like this: `function process(Point(x: 3|4, y: $y) $p): [&#39=
;a&#39; =3D&gt; int, &#39;b&#39; =3D&gt; float &amp; &gt;0]`.</div><div><br=
></div><div>--=C2=A0</div><div>Alex</div></div></div>

--000000000000416735064507e791--