[Early Feedback] Pattern matching

You won't believe it, but just right now I've been thinking about that it would be a wonderful feature for PHP to have some kind of type-tests (like `$a is Foo&Bar` or `$b is Foo|Baz|null`), and here you write out this email. I didn't read the whole RFC, but I'd like to say that having at least aforementioned type tests would be really helpful Thank you for your effort and have a nice day!

On Thu, Jun 20, 2024 at 7:41 PM Larry Garfield <larry@garfieldtech.com> wrote:

I have been looking forward to this RFC, it's such a quality of life to be able to do all this! In terms of things to focus on, I'd personally be very happy with the property/param guards, "as" and "is <regex>", but I won't say no to anything we can get extra here because it's all really nice to have. I noticed that with array structure patterns the count is omitted when using ... ```php if ($list is [1, 3, ...]) { print "Yes"; } // True. Equivalent to: if (is_array($list) && array_key_exists(0, $list) && $list[0] === 1 && array_key_exists(1, $list) && $list[1] === 3 ) { print "Yes"; } ``` Wouldn't this need a `count($list) >= 2`? I'm not sure if the underlying mechanism does the count check as well, but it seems to me like a guard clause for performance reasons in the PHP variant. Maybe a tangent, what about iterators? "Limited expression pattern" I think this would be very valuable to have, though in the proposal it seems cumbersome to use regardless of syntax. It feels like I'm going to be using the variable binding less often than matching against other variables, what about an "out" equivalent? ```php $result = match ($p) is { Point{x: 3, y: 9, $z} => "x is 3, y is 9, z is $z", Point{$x, $y, $z} => "x is $x, y is $y, z is $z", }; // vs $x = 3; $y = 9; $result = match ($p) is { Point{x: 3, y: 9, out $z} => "x is 3, y is 9, z is $z", Point{$x, $y, out $z} => "x is 3, y is 9, z is $z", }; ``` To me this makes it much more readable, just not sure if this is even feasible. This is not meant as bikeshedding the syntax, more of an alternative approach to when to use which.

Thank you!

maybe also consider: $var is mixed; // Matches anything, more useful in the structure patterns below.

+1 Regards Thomas

This definitely looks like a powerful feature I'm looking forward to. If property/param/return guards are implemented, do you see them eventually replacing the property/param/return types we have nowadays? Asking for a friend.

On 2024-06-21 05:38, Larry Garfield wrote:

As I started reading I starting thinking of "whatabouts" based on my experience with pattern matching in other languages, and as I skimmed the RFC I found each of them being addressed. I'm looking forward to this. If you want my feedback about match() "is" placement, I can see the benefits of both, and they don't look mutually exclusive, since the "is" effectively just distributes over the branches to produce the inline alternative; with that interpretation it's just an error to have "is" in the top position and something other than a type pattern in any branch because it would be equivalent to "is <not a type pattern>". I suspect the case where one is matching against a list of types will turn out to be quite common, so if "match ($somevar) is {" weren't implemented there'd soon be people asking for something equivalent to save them typing "is" over and over. One thing to note is that if "is" were to be in the top position, it means every branch has to be a type pattern, which means instead of "default" the catch-all branch would be "mixed". (That's a question: won't the branches of "match($var)is{" need to range over every possible type?) One tiny note about BC breakage:

keyword. "as" is already a global keyword (as in "foreach($arr as $e)"). So that's not such a problem after all.

On Thu, 20 Jun 2024, at 18:38, Larry Garfield wrote:

Hi Larry, I haven't time to read through the full RFC at the moment, but a couple of thoughts: As Andreas says, we should be careful not to pre-empt things that might be added to the type system in general, and end up with incompatible syntax or semantics. That particularly applies to the generic-like array<int> syntax, which is quite likely to end up in the language in some form. The "weak-mode flag" seems useful at first glance, but unfortunately PHP has multiple sets of coercion rules, and some are ... not great. It's also not immediately obvious which contexts should actually perform coercion, and which should just assert that it's *possible* (e.g. match($foo) is { ~int => (int)$foo } feels redundant). So I think that would need its own RFC to avoid being stuck with something sub-optimal. Similarly, the "as" keyword has potential, but I'm not sure about the naming, and whether it should be more than one feature. Asserting a type, casting between types, and de-structuring a type are all different use cases: $input = '123'; $id = $input as int; // looks like a cast, but actually an assertion which will fail? $handler as SpecialHandler; // looks like an unused expression, but actually an assertion? $position as [$x, $y]; // looks like its writing to $position, but actually the same as [$x, $y] = $position? It's worth noting that in languages which statically track the type of a variable, "$foo = $bar as SomeInterface" is actually a type of object cast; but in PHP, it's the value that tracks the type, and interfaces are "duck-typed", so it would be equivalent to "assert($bar is SomeInterface); $foo = $bar;" which isn't quite the same thing. Regards,

Hi Larry, I have definitely been looking forward to this. Perhaps more so than property hooks and avis.

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 = $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 mixed. 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 ``` 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 matched 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 => '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.

Hi Larry, On 20.06.24 19:38, Larry Garfield wrote:

Is is already a really nice RFC, even if not finished yet. Also haven't fully read it yet. Thank you for all your work and time put into it! I do have some questions: * For the generics-like pattern I do agree with the others that this might be dangerous for the future if we (hopefully) are going at it. * Capturing values out of a pattern and binding them to variables if matched. Where this is very helpful especially with `match`, from the syntax I would read it as a condition only. $p is Point {x: 3, y: $y}; // read as $p->y === $y but it's $y = $p->y But this is described differently $p is Point {y: 37, x:@($x)}; I think it would be more readable on switching the logic (somehow). like: $p is Point {x: 3, y: $y}; // $p->y === $y $p is Point {x: 3, y:=> $y}; // $y = $p->y * Regex pattern This one is interesting as well ... but I would expect native regex syntax first before introducing it as part of a different RFC. Similar as generics. Following up I would expect something like this:     $re = /.*/;  // RegEx object     $matches = $re->match($v); // preg_match     $v is $re; // used in pattern matching which opens up another question: Could we have an interface allowing objects to match in a specific way?     interface Matchable {         public function match(mixed $value): bool;     } Thanks for working on it! Marc

Hello Larry. Thanks for this Juicy proposal. I agree that this proposal should be proposed as a whole. If we break it down into smaller parts, there is a chance some features will not pass. I will show you that the range pattern and regex pattern have greater value than what you think, and they must be placed together with the literal pattern (in Core patterns section, not in Possible patterns section). I don't want these patterns to fail in the poll. I don't know the line between "high level" and beyond. I hope that whatever I discuss here is still "high level". 1. Is there any chance of ```is not``` or ```isnot```? I am tired looking this ugly code: ```!($foo instanceof Bar)```. If there is, there should be a restricted version of pattern: no variable binding. It doesn't make sense if the binding happens but the pattern fails. 2. ```..=``` and ```..<``` make people have to remember what the left side is: is it greater-than or greater-than-equal. What if those operators are replaced with ```=..=``` and ```<..=```? We don't have to align with other languages if they have weaknesses. 3. There are "between" and ```>``` operators explicitly shown in the proposal (in Range pattern section). I assume that ```>=```, ```<```, ```<=``` implicitly included. What about the ```%``` operator, is it also included? ```%``` is not directly produces boolean, but it can simplify pattern. Note that, we must include additional rules: if produced number is ```0``` (zero) then it will be converted to ```true```, otherwise ```false```. ``` $foo = 2024; // leap year $foo is %4; // true $bar = 2025; // not a leap year $bar is %4; // false // furthermore: $baz is array<%4>; // true if all its members are leap year ``` 4. There are numeric range patterns explicitly shown in the proposal. Hopefully there are also string range patterns. ``` $birthdate is "2000-01-01 00:00:00" <..< "2019-12-31 23:59:59"; $dateOfDeath is <"1980-01-01"; $name is "larry " =..< "larry!"; // true if first name is "larry" ``` I have no idea about string range patterns for array, since it causes error. If there is currently no solution, hopefully we don't abandon string range patterns entirely. The same case also occurs with numeric range patterns for array. 5. It is great that regular expression native syntax is now a first class citizen in php (at least for pattern matching). I found there are 2 drawbacks in this case: loss of flexibility and repeated identical patterns. These things are not found in string based regular expression. ``` // native syntax $foo is /^https:\/\/(?<hostname>[^\/]*)/; // string based: we can use any valid char as delimiter, // as long as it is not used in the pattern. $pattern = "/^https:\/\/(?<hostname>[^\/]*)/"; $pattern = "|^https://(?<hostname>[^/]*)/|"; // valid! $pattern = "@^https://(?<hostname>[^/]*)/@"; // valid! // ---------------------- // native syntax $foo is /^https:\/\/(?<hostname>[^\/]*)/ | StringBox{value: /^https:\/\/(?<hostname>[^\/]*)/}; // string based: RE stored in variable/constant can be used as many as we need $pattern = "|^https://(?<hostname>[^/]*)/|"; $foo is @RE($pattern) | StringBox{value: @RE($pattern)}; // 1st pattern is scalar string, 2nd is string encapsulated in a class // furthermore use GenericPattern as GP; class Person { public string $firstName is @RE(GP::NAME_PTRN); public string $lastName is @RE(GP::NAME_PTRN); // ... } ``` Hopefully, string based regular expression is also supported. Honestly, if I could choose whether I should support native or string-based syntax, I would choose to support string-based, as long as native syntax is not yet fully supported in general. ```@RE()``` is just an illustration on how to use variable as a regular expression in the pattern. It is stated that ```@()``` will be used in arbitrary expressions. Correct me if I'm wrong, regexp are one of the things in programming that cannot be manipulated or participate in manipulation with other parties, even with fellow regexp. Regexp must be used alone. That is why we need dedicated syntax for regexp. 6. It is shown that type pattern, literal pattern, class constant pattern, and expression pattern can be used to form a compound pattern. Hopefully, the range pattern and regex pattern have the same luxury. Furthermore, hopefully they can be mixed. ``` $foo is 2000 =..= 2100 & %4; // leap year in 21st century class person { public string $firstName is /LENGTH_PTRN/ & /FORBIDDEN_CHARS_PTRN/ & /FORBIDDEN_WORDS_PTRN/; public string $lastName is @RE(GP::LENGTH_PTRN) & @RE(GP::FORBIDDEN_CHARS_PTRN) & @RE(GP::FORBIDDEN_WORDS_PTRN); // these are hard to maintain public string $firstName is @RE(GP::COMPLEX_NAME_PTRN); public string $lastName is @RE(GP::COMPLEX_NAME_PTRN); } 7. I noticed that ```as``` is tightly coupled with exception. Can we suppress this exception with ```??```? ``` // it is weird to see this statement (as show in the proposal) $value = $foo as Foo {$username, $password}; // these statements are more make sense $foo as Foo {$username, $password}; $foo is Foo {$username, $password} ?: throw new Exception(); // if it can be suppressed, "as" is more valuable than what people think. $newRect = $rect as Rectangle{width: <=10, height: <=5} ?? new Rectangle(width: 10, height: 5); ``` 8. Is there any type checking for object property pattern? ``` class Circle { public int $radius; } // this statement will always fails unless there is type checking $circle is Circle{radius: "10"}; ``` ~~~~~ 4 of the 8 points I discussed above are related to range pattern and regex pattern. Both are used daily. From my point of view, literal pattern is no more special than range pattern and regex pattern. IMO, both should be placed in Core patterns section, not in Possible patterns section. Regards, Hendra Gunawan.

[THIS REPLY IS FOR THE CONVENIENCE OF https://externals.io READERS ONLY. SORRY FOR THE UNPLEASANT DISPLAY] Hello Larry. Thanks for this Juicy proposal. I agree that this proposal should be proposed as a whole. If we break it down into smaller parts, there is a chance some features will not pass. I will show you that the range pattern and regex pattern have greater value than what you think, and they must be placed together with the literal pattern (in Core patterns section, not in Possible patterns section). I don't want these patterns to fail in the poll. I don't know the line between "high level" and beyond. I hope that whatever I discuss here is still "high level". 1. Is there any chance of ```is not``` or ```isnot```? I am tired looking this ugly code: ```!($foo instanceof Bar)```. If there is, there should be a restricted version of pattern: no variable binding. It doesn't make sense if the binding happens but the pattern fails. 2. ```..=``` and ```..<``` make people have to remember what the left side is: is it greater-than or greater-than-equal. What if those operators are replaced with ```=..=``` and ```<..=```? We don't have to align with other languages if they have weaknesses. 3. There are "between" and ```>``` operators explicitly shown in the proposal (in Range pattern section). I assume that ```>=```, ```<```, ```<=``` implicitly included. What about the ```%``` operator, is it also included? ```%``` is not directly produces boolean, but it can simplify pattern. Note that, we must include additional rules: if produced number is ```0``` (zero) then it will be converted to ```true```, otherwise ```false```. ``` $foo = 2024; // leap year $foo is %4; // true $bar = 2025; // not a leap year $bar is %4; // false // furthermore: $baz is array<%4>; // true if all its members are leap year ``` 4. There are numeric range patterns explicitly shown in the proposal. Hopefully there are also string range patterns. ``` $birthdate is "2000-01-01 00:00:00" <..< "2019-12-31 23:59:59"; $dateOfDeath is <"1980-01-01"; $name is "larry " =..< "larry!"; // true if first name is "larry" ``` I have no idea about string range patterns for array, since it causes error. If there is currently no solution, hopefully we don't abandon string range patterns entirely. The same case also occurs with numeric range patterns for array. 5. It is great that regular expression native syntax is now a first class citizen in php (at least for pattern matching). I found there are 2 drawbacks in this case: loss of flexibility and repeated identical patterns. These things are not found in string based regular expression. ``` // native syntax $foo is /^https:\/\/(?<hostname>[^\/]*)/; // string based: we can use any valid char as delimiter, // as long as it is not used in the pattern. $pattern = "/^https:\/\/(?<hostname>[^\/]*)/"; $pattern = "|^https://(?<hostname>[^/]*)/|"; // valid! $pattern = "@^https://(?<hostname>[^/]*)/@"; // valid! // ---------------------- // native syntax $foo is /^https:\/\/(?<hostname>[^\/]*)/ | StringBox{value: /^https:\/\/(?<hostname>[^\/]*)/}; // string based: RE stored in variable/constant can be used as many as we need $pattern = "|^https://(?<hostname>[^/]*)/|"; $foo is @RE($pattern) | StringBox{value: @RE($pattern)}; // 1st pattern is scalar string, 2nd is string encapsulated in a class // furthermore use GenericPattern as GP; class Person { public string $firstName is @RE(GP::NAME_PTRN); public string $lastName is @RE(GP::NAME_PTRN); // ... } ``` Hopefully, string based regular expression is also supported. Honestly, if I could choose whether I should support native or string-based syntax, I would choose to support string-based, as long as native syntax is not yet fully supported in general. ```@RE()``` is just an illustration on how to use variable as a regular expression in the pattern. It is stated that ```@()``` will be used in arbitrary expressions. Correct me if I'm wrong, regexp are one of the things in programming that cannot be manipulated or participate in manipulation with other parties, even with fellow regexp. Regexp must be used alone. That is why we need dedicated syntax for regexp. 6. It is shown that type pattern, literal pattern, class constant pattern, and expression pattern can be used to form a compound pattern. Hopefully, the range pattern and regex pattern have the same luxury. Furthermore, hopefully they can be mixed. ``` $foo is 2000 =..= 2100 & %4; // leap year in 21st century class person { public string $firstName is /LENGTH_PTRN/ & /FORBIDDEN_CHARS_PTRN/ & /FORBIDDEN_WORDS_PTRN/; public string $lastName is @RE(GP::LENGTH_PTRN) & @RE(GP::FORBIDDEN_CHARS_PTRN) & @RE(GP::FORBIDDEN_WORDS_PTRN); // these are hard to maintain public string $firstName is /COMPLEX_NAME_PTRN/; public string $lastName is @RE(GP::COMPLEX_NAME_PTRN); } ``` 7. I noticed that ```as``` is tightly coupled with exception. Can we suppress this exception with ```??```? ``` // it is weird to see this statement (as show in the proposal) $value = $foo as Foo {$username, $password}; // these statements are more make sense $foo as Foo {$username, $password}; $foo is Foo {$username, $password} ?: throw new Exception(); // if it can be suppressed, "as" is more valuable than what people think. $newRect = $rect as Rectangle{width: <=10, height: <=5} ?? new Rectangle(width: 10, height: 5); ``` 8. Is there any type checking for object property pattern? ``` class Circle { public int $radius; } // this statement will always fails unless there is type checking $circle is Circle{radius: "10"}; ``` ~~~~~ 4 of the 8 points I discussed above are related to range pattern and regex pattern. Both are used daily. From my point of view, literal pattern is no more special than range pattern and regex pattern. IMO, both should be placed in Core patterns section, not in Possible patterns section. Regards, Hendra Gunawan.

On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote:

Hi folks. Thank you to those who have offered feedback so far. Based on the discussion, here's what we're thinking of doing (still subject to change, of course): * We're going to move `as` to future-scope. There's enough weirdness around it that is independent of pattern matching itself that it will likely require its own discussion and RFC, and may or may not involve full pattern support. * Similarly, we're going to hold off on the weak-mode flag. It sounds like the language needs to do more to fix the definition of "weak mode" before it's really viable. :-( On the plus side, if the type system itself ever adds support for a "coercion permitted" flag, patterns should inherit that naturally, I think. * Array-application will also be pushed to future-scope. Again, there's enough type-system tie in here that is tangential to patterns that we'll pick that fight later. * Ilija and I have discussed regex patterns a bit further, and it sounds like they’re going to be rather complicated to implement. Even assuming we agree on the syntax for it, it would be a substantial amount of code to support. (It’s not like types or literals or range where we can just drop something pre-existing into a new function.) So we’re going to hold off on this one for now, though it does seem like a high-priority follow-up for the future. (Which doesn’t have to be us!) So let's not discuss the above items further at this point. * I'm going to do some additional research into other languages to see how they handle binding vs using variables from scope, and what syntax markers they use and where. Once we have a better sense of what is out there and is known to work, we can make a more informed plan for what we should do in PHP. (Whether using a variable from scope in the pattern is part of the initial RFC is still an open question, but we do need to design it alongside the capture part to ensure they don't conflict.) Stay tuned on this front. * We've removed the dedicated wildcard pattern, as it's equivalent to `mixed`. If there's interest, we're open to having a secondary vote to bring it back as a short-hand pattern. It's trivial to implement and we don't have strong feelings either way. * There's not been much discussion of range patterns. Anyone want to weigh in on those? * The placement of `is` on `match()` is still an open question. * No one has really weighed in on nested patterns for captured variables. Any thoughts there? * I’ve seen a suggestion for capturing the “rest” of an array when using … That’s an interesting idea, and we’ll explore it, though it looks like it may have some interesting implications that push it to future scope. It feels like a nice-to-have. Thanks all. --Larry Garfield

Le jeudi 20 juin 2024, 19:38:40 UTC+2 Larry Garfield a écrit :

Hello, Thank you for this RFC. Sorry if that’s a bit focused on syntax, but I’m really concerned by the binding syntax. I would totally expect both these codes to do the same thing: ``` if ($o is Class{prop: 3}) { ``` and: ``` $x = 3; if ($o is Class{prop: $x}) { ``` I’ve seen someone else in the discussion propose to invert the logic between binding and use a variable and I agree, it’s the binding/capture which should have the special syntax. Either another operator than ':', I’ve seen '=>' proposed. Or any other idea to differentiate it. '=>' would allow to combine match and capture like this: $o is Class{prop: int => $y} Côme