Re: [RFC] Pattern Matching
| From: | Larry Garfield | Date: | Wed, 03 Dec 2025 15:56:15 +0000 |
| Subject: | Re: [RFC] Pattern Matching | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-129526@lists.php.net to get a copy of this message | ||
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 <larry@garfieldtech.com> 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