Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123796
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <d06e5a04-9601-4af4-bdad-4f5e92bc5e18@app.fastmail.com>
In-Reply-To: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
Date: Mon, 24 Jun 2024 23:31:56 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:

> To that end, we're looking for *very high level* feedback on this RFC:
>
> https://wiki.php.net/rfc/pattern-matching

Hi folks.  Thank you to those who have offered feedback so far.  Based o=
n the discussion, here's what we're thinking of doing (still subject to =
change, of course):

* We're going to move `as` to future-scope.  There's enough weirdness ar=
ound it that is independent of pattern matching itself that it will like=
ly require its own discussion and RFC, and may or may not involve full p=
attern support.

* Similarly, we're going to hold off on the weak-mode flag.  It sounds l=
ike the language needs to do more to fix the definition of "weak mode" b=
efore it's really viable. :-(  On the plus side, if the type system itse=
lf ever adds support for a "coercion permitted" flag, patterns should in=
herit that naturally, I think.

* 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'l=
l pick that fight later.

* 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 amoun=
t 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 see=
m like a high-priority follow-up for the future.  (Which doesn=E2=80=99t=
 have to be us!)

So let's not discuss the above items further at this point.

* I'm going to do some additional research into other languages to see h=
ow they handle binding vs using variables from scope, and what syntax ma=
rkers they use and where.  Once we have a better sense of what is out th=
ere and is known to work, we can make a more informed plan for what we s=
hould 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 de=
sign it alongside the capture part to ensure they don't conflict.)  Stay=
 tuned on this front.

* We've removed the dedicated wildcard pattern, as it's equivalent to `m=
ixed`.  If there's interest, we're open to having a secondary vote to br=
ing it back as a short-hand pattern.  It's trivial to implement and we d=
on't have strong feelings either way.

* There's not been much discussion of range patterns.  Anyone want to we=
igh in on those?

* The placement of `is` on `match()` is still an open question.

* No one has really weighed in on nested patterns for captured variables=
.  Any thoughts there?

* 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, a=
nd we=E2=80=99ll explore it, though it looks like it may have some inter=
esting implications that push it to future scope.  It feels like a nice-=
to-have.

Thanks all.

--Larry Garfield