On Mon, Jun 15, 2026, at 7:44 PM, Seifeddine Gmati wrote:
>> On Mon, Jun 15, 2026, 20:05 Seifeddine Gmati <[email protected]>
>> wrote:
>>> While this RFC works alongside the pattern matching proposal by Larry and
>>> Ilija, neither requires the other. The two are unrelated for several
>>> reasons.
>>>
>>> So to answer your question, no, I am not looking for pattern matching. I
>>> see these as two distinct features that address different needs within the
>>> language.
>>
>> I don't believe they are addressing entirely different needs. I believe the
>> feature that static analysis tools support is pattern matching more than it
>> is typing. The question for me becomes whether patterns be represented
>> through types, or whether they should be matched against values.
>>
>> Strictly denoting types and validating patterns are two separate concerns.
>> One asks "What can I do with this?" while the other asks "Is this within
>> expected bounds?". I am personally not against validating patterns within
>> type declarations, as is supported in Typescript, Scala (I believe), and to
>> an extent PHP with false|true. But I do believe they are different concerns.
>>
>> I also think that, this being a form of pattern matching, if approved would
>> set a direction for the pattern matching RFC to treat patterns more closely
>> as types than assertions and guards (as their RFC currently proposes). I am
>> again not saying this is a bad thing, but it is worth acknowledging.
>
> Hi Sarina,
>
> I don't think we disagree here. I already said above that I think
> pattern matching should match against types with variable binding; this
> actually makes pattern matching easier because to expand it, you just
> have to expand the type system, and patterns get expanded for free.
>
> However, I think this is a discussion for the pattern matching RFC, not
> for the literal types RFC.
>
> Cheers,
> Seifeddine.
This is interesting. We've approached patterns as a coincidental superset of
the type system. That is, (almost) any type declaration is a valid pattern,
but not because patterns are types; because we've implemented patterns to
mirror types.
Patterns *as* types would be a completely different approach. I can see the
appeal, but there's a number of issues there:
1. Performance. Patterns do a lot more work than a type check right now. If
patterns cropped up in function signatures all over the place, that would have
a notable, though currently unclear and hard to predict, impact on performance.
(Far more inconsistent than, say, reified generics would have...)
2. Complexity. Expanding the type system to full patterns seems like it would
be... hard. And possibly internal-API breaking. I could be completely wrong
here, but it sounds like a fairly drastic change.
3. Repeatability. For this to work, I think it would *have* to include type
definitions, which have always hit a discussion wall in the past as no one can
agree on their design. Something like:
type positiveInt = int & >0;
type UserId = int;
type order = 'asc'|'desc';
function foo(positiveInt $val) { ... } // Guaranteed to be an integer greater
than 0
function bar(UserId $id) { ... } // Would this accept a positiveInt? Debatable.
There's a sizable rabbit hole here. One could argue even that for scalar
literal types we should have proper type defs.
4. Variable binding. Let me be clear: Variable binding *is* the feature that
makes pattern matching worthwhile. It's the reason we started working on it;
we believe it is a prerequisite for properly implementing ADTs/"tagged enums."
So even if patterns become types, there will still be a need for an extended
variable binding syntax that works only inline, not as part of a type
declaration. What the complexity impact of that would be, I have no idea.
If there is a consensus to go down this rabbit hole, I am not opposed to it.
But it's a very deep rabbit hole, and exploring it would guarantee that neither
patterns nor scalar literal types make it into this version. It would probably
also entail 3-4 RFCs total, all of which would be kind of half-arsed on their
own because they're part of a set; and PHP has been extremely, *extremely* bad
at coordinating and working with that in the past. (Maybe a place for working
groups?)
--Larry Garfield
