Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126301
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 05 Feb 2025 22:55:44 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <98aac8cf-fb19-4bf1-9deb-1e3c450e3207@app.fastmail.com>
In-Reply-To: <72a771e1-dc1e-4dcf-ab93-3566e8fb68ff@app.fastmail.com>
References: <febe86f4-db37-4ea0-84ef-a30d59d832af@app.fastmail.com>
 <da29a750-9d34-428b-8356-8eedd629af0c@app.fastmail.com>
 <25b1011b-b2c4-4f5c-8e83-694c59ee29eb@mabe.berlin>
 <3bb77a10-f716-4729-9bc4-4b87772598a5@app.fastmail.com>
 <72a771e1-dc1e-4dcf-ab93-3566e8fb68ff@app.fastmail.com>
Subject: Re: [PHP-DEV] Pattern matching details questions
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Feb 4, 2025, at 4:30 PM, Rob Landers wrote:
> On Tue, Feb 4, 2025, at 22:16, Larry Garfield wrote:

>> Patterns are deliberately designed as a superset of existing DNF types.  You can already have a type of Foo&Bar, so we want the pattern for "instanceof Foo || instanceof Bar" to be the same.  That means & and | for conjunctions is necessary.  Also supporting "and" and "or" would technically be possible, but wouldn't resolve the issue (since & would still be needed either way) and would just add more complication, confusion, and inconsistency.  I don't think that's viable.
>
> Interesting way of looking at it, not wrong either. I guess I'm not 
> used to this syntax that much. It's like reading the following 
> statement and working out what the value is without running it:

Well, right now no one is used to it. :-)  Unless they've spent a lot of time in Rust.  Ilija and I have been staring at it longer than anyone else, obviously, but any new feature is, well, new.

> Personally, it might be worth adding binding/setting values until a 
> later RFC just to reduce the complexity until people get used to it. 
> Right now, you (and maybe a couple of others) are probably the only 
> people on earth who can truly understand how the syntax actually works; 
> the rest of us may not _yet_ be equipped to give useful feedback.

That's been suggested a few times.  The challenge here is:

1. variable binding is a core part of pattern matching in basically every language that has it.  The decomposition capability is the primary use case.  So leaving that out gives us... basically a more compact way to chain instanceof, which isn't that impressive.
2. Variable pinning is an optional feature, most languages don't have it, but it's a nice-to-have.  It would be fine to punt to later.
3. Except we really need to ensure that the syntax for variable binding doesn't cause problems for a future variable pinning feature due to syntax/parsing confusion.  That means we have to do at least a large chunk of the design and trial implementation up-front to make sure we're not painting ourselves into a corner.
4. At which point, we've basically implemented pinning anyway so may as well just include it.

--Larry Garfield