Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129514
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 02 Dec 2025 14:06:15 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <cef355bf-8066-4b06-a999-f313fbae5474@app.fastmail.com>
In-Reply-To: 
 <CAAwdEzDOd5v2UX4Ms8pn+73aSaVA1EMBr2n3c6RWztb5Fmanbg@mail.gmail.com>
References: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
 <CAAwdEzDOd5v2UX4Ms8pn+73aSaVA1EMBr2n3c6RWztb5Fmanbg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Pattern Matching
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Dec 2, 2025, at 6:28 AM, Alexandru P=C4=83tr=C4=83nescu wrote:
> On Mon, Dec 1, 2025 at 11:39=E2=80=AFPM Larry Garfield <larry@garfield=
tech.com> wrote:
>> Hi folks.  Ilija and I would like to present our latest RFC endeavor,=
 pattern matching:
>>=20
>> https://wiki.php.net/rfc/pattern-matching
>>=20
>
> Great work, very detailed and well written.

Thanks!

> 1. There are mentions that any type present in a function parameter=20
> signature and return value is a valid pattern matching.
> But are there any plans to extend the pattern-matching-syntax to=20
> parameter types and return values?
>
> Of course, with some restrictions: without variable pinning.And withou=
t=20
> variable binding on return type, but that could work on parameter type=
s.
> If that's possible or already planned, I think it's worth mentioning i=
t=20
> 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.

> 2. Maybe some parts of the RFC could be separated to reduce complexity.
> Thinking about variable pinning.

Actually, with the new implementation variable pinning turned out to be =
stupidly easy.  That was a convenient bonus, which is why we included it=
 in the initial RFC.  It was originally in future scope, but the diff to=
 add it was like 10 lines or something, so we included it now.  The futu=
re-scopes that are still in future-scope are all "harder than they look"=
 or "deciding what exactly to do will be a lot of discussion", which is =
why they're there and not in the base release.

> 3. For match() "is" placement, I would go with the second form as it's=20
> more flexible, but I think allowing both forms might be nice if the=20
> complexity is not too high.
> Or go only with the second form now, and add the first form later in a=20
> smaller RFC.

Noted!  I think that's one vote for a single is, and one vote for a sepa=
rate one for each arm. :-)

--Larry Garfield