Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129925
Message-ID: <49cb415d-adb9-408d-82af-b71f6de234ad@varteg.nz>
Date: Mon, 26 Jan 2026 17:47:35 +1300
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Pattern Matching
To: internals@lists.php.net
References: <e25ea0a6-bb82-4762-9e51-a543d0e6efe5@app.fastmail.com>
 <56dce794-a512-421a-a8d2-91a9692c1ab4@app.fastmail.com>
 <a3e190b10c98a7574ce471a7f1ee51fb@bastelstu.be>
 <23093833-bdd2-442d-86b8-9ef492c51ad1@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <23093833-bdd2-442d-86b8-9ef492c51ad1@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: weedpacket@varteg.nz (Morgan)

On 2026-01-26 07:44, Larry Garfield wrote:
> 
> With per-arm, you can opt-in to pattern matching individually, at the cost of having to remember to repeat the keyword on every line.  With per-block, you only have to add the keyword once at the cost of not being able to selectively use patterns or identity matching.
> 
> Which tradeoff is better is the option question.  (Ilija and I disagree on which to go with.)  Or, if someone can suggest a way to allow automatic detection reliably, that would also be most welcome. :-)
> 

If it had to be one or the other, then arms-only would be my choice as 
the more flexible of the two - and it's the one we have now, so the real 
question is if "match($foo) is {..." should be added as a shorthand for 
when all matching is on patterns.

I'm leaning toward "yes", especially as scalar literals would pattern 
match by value identity anyway. Falling back on per-arm "is" would only 
be necessary to address those class/constant confusions if and when they 
arise - but when they do you'll want it to be possible to address them.

But if "is" were required on every pattern match, that's a lot of 
"is"ing. People would get into the habit of using it like "case" in a 
switch statement (or putting backticks around every single identifier in 
a MySQL query), using it even when a value match is sufficient. And then 
having it bite them precisely in those cases when there is something 
like a class/constant confusion.