Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129498
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] [RFC] Pattern Matching
Date: Tue, 2 Dec 2025 08:24:43 +0700
Message-ID: <6FCEAC03-2EAD-440D-8D8B-6D014C16C149@koalephant.com>
References: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
Cc: php internals <internals@lists.php.net>
In-Reply-To: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
From: php-lists@koalephant.com (Stephen Reay)



> On 2 Dec 2025, at 04:45, Larry Garfield <larry@garfieldtech.com> wrote:
>=20
> =EF=BB=BFHi folks.  Ilija and I would like to present our latest RFC endea=
vor, pattern matching:
>=20
> https://wiki.php.net/rfc/pattern-matching
>=20
> You may note the date on the RFC is from 2020.  Yes, we really have had th=
is one in-progress for 5 years. :-)  (Though it was inactive for many of tho=
se years, in fairness.)  Pattern matching was intended as the next follow up=
 to Enums, as it's a stepping stone toward full ADT support.  However, we al=
so feel it has enormous benefit on its own for simplifying complex compariso=
ns.
>=20
> This RFC has been through numerous iterations, including a full implementa=
tion rewrite just recently that made a number of features much easier.  We h=
ave therefore included two patterns that were previously slated for later in=
clusion but turned out to be trivially easy in the new approach.  (Variable p=
inning and numeric comparison.)
>=20
> Nonetheless, there are two outstanding questions on which we are looking f=
or feedback.
>=20
> Naturally given the timing, we will not be calling a vote until at least l=
ate January, regardless of how the discussion goes.  So, plenty of time to e=
xpress your support. :-)
>=20
> --
>  Larry Garfield
>  larry@garfieldtech.com
>=20

Hi Larry,=20

Is there a specific reason why less than/etc comparison (and the future scop=
e of ranges) is limited to numerics?

'A' < 'K' comparisons  are already in the language, and range() accepts stri=
ng arguments to produce an array of bytes.

Cheers

Stephen=