Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123741
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-522-ga39cca1d5-fm-20240610.002-ga39cca1d
Precedence: bulk
MIME-Version: 1.0
Message-ID: <c66a9540-5701-4743-ac41-f3a34e784161@app.fastmail.com>
In-Reply-To: 
 <CAB_ngDjrZYC2ecsU9mgZ3kjMQnsy3PhYjLt8chPUZ=RDSwT9RQ@mail.gmail.com>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <CAB_ngDjrZYC2ecsU9mgZ3kjMQnsy3PhYjLt8chPUZ=RDSwT9RQ@mail.gmail.com>
Date: Fri, 21 Jun 2024 18:19:27 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jun 21, 2024, at 3:35 PM, Brandon Jackson wrote:
>> Ilija and I have been working on and off on an RFC for pattern matching since the early work on Enumerations.  A number of people have noticed and said they're looking forward to it.
>
> Hi Larry, I have definitely been looking forward to this. Perhaps more
> so than property hooks and avis.
>
>> By "very high level," I mean, please, do not sweat specific syntax details right now.  That's a distraction.  What we're asking right now is "which of these patterns should we spend time sweating specific syntax details on in the coming weeks/months?"  There will be ample time for detail bikeshedding later, and we've identified a couple of areas where we know for certain further syntax development will be needed because we both hate the current syntax. :-)
>
> I think that a lot of this would be best broken up. Although much of
> it is aimed towards the same general idea, a lot of the pieces have
> specific use cases and special syntax additions. Overall I think this
> rfc should be simplified to just pattern matching with the `is`
> keyword with the patterns limited to what can be declared as property
> types (DNF types) and future scoping everything else. Maybe possibly
> with the addition of 1 or 2 of the top requested `is` pattern matching
> capabilities as secondary votes.

To give more context, as noted, this is a stepping stone toward ADTs.  Anything that is on the "hot path" for ADT support I would consider mandatory, so trying to split it up will just take more time and effort.  That includes the object pattern and match support, and the object pattern realistically necessitates literals.  Variable binding would also be almost mandatory for ADTs.  I'm very reluctant to push off anything in that hot path, as every RFC has additional overhead, and I'm all volunteer time. :-)

> 1. `as`
> `is` and `as` have different responsibilities. I'm guessing the idea
> is to keep them in sync. But I would still like to see this as a
> future scope with a separate rfc. I do like the idea, and believe it's
> much needed. But I think the pattern matching portion `is` overshadows
> the `as` portion causing it not to get as much attention as far as
> discussion and analysis goes. Especially if the idea is to sync them,
> then that makes `as` just as big of an addition as `is`
>
> For example, what if instead, a generally prefered solution/syntax
> were variable types, something like:
> `var Foo&Bar $my_var = $alpha->bravo;`
> Although casting and declaring are 2 separate things. This seems like
> it would accomplish the same thing without the extra keyword, with the
> exception of casting being inline. How much would it get used if both
> were added? Would one then become an "anti-pattern"?

As proposed, `as` is basically:

$foo as Bar|Baz
// Becomes
if (! $foo is Bar|Baz) {
  throw \Exception();
}

So it would be pretty easy to do, I believe.  Whether that's what we *want* `as` to be, that's a fair question.  

> 2. Literal patterns
> Again a really nice addition. Love it and likely will be loved by
> many. Although, it definitely deserves its own separate discussion.
> Looking at typescript which has both enums and literal types (although
> vastly different in php) caused what was once considered a nice
> feature to be black listed by many. Also note how typescript separates
> type land and value land. Maybe worth considering.

As noted above, I don't think it's feasible to postpone this one.  It's also pretty simple, and wouldn't have any conflict with enums unless we went all in on the guards options, which we most likely will not in the initial version.

> 3. Wild card
> Has already been marked as not necessary it looks like and replaced by mixed.

Some people still want it, even though it's redundant, so it may end up as a secondary vote.  I don't much care myself either way.

> 4. Object matching
> Absolutely a separate rfc please. Definitely needs discussion. Could
> intersect another potentially preferred solution like type aliases.
> Sending one or the other into anti-pattern world.
> Maybe a solution similar to this would be preferred:
>
> ```php
> type MyType = Foo&Bar
> $foo = $bar as MyType|string
> ```

As noted, this is on the ADT hot path so postponing it is problematic.  Especially holding it on type aliases, which have been discussed for longer than this RFC has been around (nearly 4 years) and yet no actual proposal has ever been put forward.  It's unwise to wait for such a feature, especially when most likely implementations would dovetail well with patterns anyway.

> 5. Array sequence patterns
> More in depth discussion needed. Not sure how often this comes up as a
> structure people want to check against, but it can definitely be done
> in user land with array slices. Even though it might be nice for
> completion's sake, it may not be worth it if there's not high demand
> for it. If at all could be grouped with associative array patterns.
>
> 6. Associative array patterns
> Love to have this one, but it also seems like a small extension or
> conflicting with array shapes. Also potentially conflicts with
> generics (which may or may not ever be a thing) but still let's give
> it the attention it needs. Maybe group with array shapes as well.
>
> 7. Array shapes
> Same as above

To clarify here, these all come as a set.  Array shapes aren't their own "thing", they just fall out naturally from array patterns.  So it's not possible for associative patterns to conflict with array shapes, as they are literally the same thing. :-)  I'd have to check with Ilija but I don't believe there's much internal difference between list and associative patterns.  This one isn't on the ADT hot path, so it could be postponed 

I see no way for associative array patterns/shapes to conflict with generics at all.  

> 8. Capturing values out of a pattern and binding them to variables if matched
> Ok I think that's stepping a bit far out of scope. Maybe `is` should
> simply check and not have any side effects.

As above, this is core functionality of pattern matching for ADTs, as well as a core feature of every other language that has pattern matching, I believe.  It's not out of scope, it's core scope.

> 9. match .. is
> Nice shorthand to have but i'd rather not see short hands forced in as
> an all or nothing type thing as was done with property hooks. I'd also
> argue that maybe short hands should not be added until a feature has
> been around for at least one release and is generally accepted. That
> way we're not using up syntaxes and limiting the ability to add other
> syntax features without breaking backwards compatibility. Keep in mind
> that the `is` functionality alone allows this (or at least it should)
> and a shorter version may or may not be desired.
> ```php
> match(true) {
>   $var is Foo => 'foo',
>   ...
> }
> ```

This is also core scope of pattern matching in most languages.  It's not just a shorthand, it's a direct enhancement.

--Larry Garfield