On Wed, Dec 3, 2025, at 2:21 AM, Alexandru Pătrănescu wrote: > On Tue, Dec 2, 2025 at 10:09 PM Larry Garfield <[email protected]> wrote: >> >> >> > 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. >> > > That is not exactly what I meant. > Since all types are valid patterns, can't we enlarge the type set to > include more things from the pattern set? in future RFCs. > Something like this: `function process(Point(x: 3|4, y: $y) $p): ['a' > => int, 'b' => float & >0]`. > > -- > Alex
Yes, that's also in speculative extensions, under the "Parameter or return guards" section. :-) I think it would be cool (especially if combined with Rob's type aliases), but that's out of scope for now. --Larry Garfield
