Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123732
Precedence: bulk
MIME-Version: 1.0
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
In-Reply-To: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
Date: Fri, 21 Jun 2024 10:35:53 -0500
Message-ID: <CAB_ngDjrZYC2ecsU9mgZ3kjMQnsy3PhYjLt8chPUZ=RDSwT9RQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: brandonja991@gmail.com (Brandon Jackson)

> Ilija and I have been working on and off on an RFC for pattern matching s=
ince the early work on Enumerations.  A number of people have noticed and s=
aid 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 detail=
s 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 bikeshedd=
ing 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.

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 =3D $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"?

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.

3. Wild card
Has already been marked as not necessary it looks like and replaced by mixe=
d.

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 =3D Foo&Bar
$foo =3D $bar as MyType|string
```

Or maybe not, either way I think it needs its own spotlight.

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

8. Capturing values out of a pattern and binding them to variables if match=
ed
Ok I think that's stepping a bit far out of scope. Maybe `is` should
simply check and not have any side effects.

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 =3D> 'foo',
  ...
}
```

** This is not an order of preference by any means, just listed as
seen in the rfc. **

I'll stop there, and hope the message is received. In summary I would
be plenty grateful for just being able to check against DNF types
initially with support for more pattern types in the near or distant
future.

I think array shapes and literal types are the only ones I'd hope for
a sooner rather than later follow up rfc targeted hopefully for the
same release. Maybe even as secondary votes. The others I'm ok with
waiting for and would rather see follow up rfcs on them as time
permits.