On Tue, Dec 2, 2025, at 6:28 AM, Alexandru Pătrănescu wrote: > On Mon, Dec 1, 2025 at 11:39 PM Larry Garfield <[email protected]> wrote: >> Hi folks. Ilija and I would like to present our latest RFC endeavor, >> pattern matching: >> >> https://wiki.php.net/rfc/pattern-matching >> > > Great work, very detailed and well written.
Thanks! > 1. There are mentions that any type present in a function parameter > signature and return value is a valid pattern matching. > But are there any plans to extend the pattern-matching-syntax to > parameter types and return values? > > Of course, with some restrictions: without variable pinning.And without > variable binding on return type, but that could work on parameter types. > If that's possible or already planned, I think it's worth mentioning it > in the future scope section. See the linked "speculative extensions" document. It's mentioned there, but it hasn't gone beyond "Larry thinks it would be kinda cool to write `public int $x is >0`. That's definitely out of scope for now, but I'm very open to discussing it in the future. > 2. Maybe some parts of the RFC could be separated to reduce complexity. > Thinking about variable pinning. Actually, with the new implementation variable pinning turned out to be stupidly easy. That was a convenient bonus, which is why we included it in the initial RFC. It was originally in future scope, but the diff to add it was like 10 lines or something, so we included it now. The future-scopes that are still in future-scope are all "harder than they look" or "deciding what exactly to do will be a lot of discussion", which is why they're there and not in the base release. > 3. For match() "is" placement, I would go with the second form as it's > more flexible, but I think allowing both forms might be nice if the > complexity is not too high. > Or go only with the second form now, and add the first form later in a > smaller RFC. Noted! I think that's one vote for a single is, and one vote for a separate one for each arm. :-) --Larry Garfield
