Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129908
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 23 Jan 2026 13:48:31 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <56dce794-a512-421a-a8d2-91a9692c1ab4@app.fastmail.com>
In-Reply-To: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
References: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Pattern Matching
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Dec 1, 2025, at 3:36 PM, Larry Garfield wrote:
> Hi folks.  Ilija and I would like to present our latest RFC endeavor, 
> pattern matching:
>
> https://wiki.php.net/rfc/pattern-matching
>
> You may note the date on the RFC is from 2020.  Yes, we really have had 
> this one in-progress for 5 years. :-)  (Though it was inactive for many 
> of those 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 also feel it has enormous benefit on its own for 
> simplifying complex comparisons.
>
> This RFC has been through numerous iterations, including a full 
> implementation rewrite just recently that made a number of features 
> much easier.  We have therefore included two patterns that were 
> previously slated for later inclusion but turned out to be trivially 
> easy in the new approach.  (Variable pinning and numeric comparison.)
>
> Nonetheless, there are two outstanding questions on which we are 
> looking for feedback.
>
> Naturally given the timing, we will not be calling a vote until at 
> least late January, regardless of how the discussion goes.  So, plenty 
> of time to express your support. :-)

Happy New Year!

Tim brought up some interesting points around parsing edge cases, which we're still discussing off list.  Once we have a proposal (or multiple) to consider, we'll get back to that part.

Meanwhile, there's a few outstanding issues that we do still want/need broader feedback on.  Even if you just want to state a bikeshed preference, please do so.  (Though an explanation of why is always helpful.)

1. match() statements.  There's two ways we could do this: All-branches, or individual branches.  This is particularly important as, in practice, we expect match() to be the most common use of patterns.

// All-branches: 
$result = match ($somevar) is {
    Foo => 'foo',
    Bar => 'bar',
    Baz|Beep => 'baz',
    Qix, Nox => 'qix',
};

// Individual branches
$result = match ($somevar) {
    is Foo => 'foo',
    is Bar => 'bar',
    is Baz|Beep => 'baz',
    is Qix, Nox => 'qix',
};

The idea of the second being that, if you want just an identity match, you can skip adding `is` on just that one arm.  While it would be lovely to do that automatically, we cannot differentiate between a class name and a constant so that's not really feasible.

Of note, most language with this functionality have no "non-pattern" equivalent of match(), so the issue doesn't come up.  The only one that does, Ruby, uses a different prefix keyword depending if it's pattern or equality based, BUT you have to use the same keyword for all branches.


2. Positional array patterns.  How picky should the pattern matching be for list-esque arrays?  There's 3 options listed in the RFC as possible ways forward, so I won't repeat them here but just provide a link: 

https://wiki.php.net/rfc/pattern-matching#positional_array_enforcement


3. Do we want to have a pattern for "match an object's properties without specifying what type the object has to be?"  If so, what syntax should it be?  Just omitting the class name (producing `$o is {x: 1}` ) is not possible.  We tried. :-)  Options include:

`$o is _(x: 1)`
`$o is object(x: 1)` 
// Your suggestion here.

4. The variable pinning syntax.  There's been some concerns about it being non-obvious, which is valid.  The main argument for it is "it's what Ruby does", which is not the most compelling argument, but it's not invalid.

Is there some other syntax that would work better?  Ilija has pondered `{$x}`, which would then potentially allow simple expressions inside the pattern within the {}.  I am a little scared of the scope creep potential. :-)  But we're open to having this discussion, so please discuss.

Please do weigh in and help us decide on a way forward for these.

--Larry Garfield