Hey Larry,
> Am 16.06.2026 um 17:16 schrieb Larry Garfield <[email protected]>:
>
> 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...)
The performance impact is certainly lower than manually validating all over the
place.
Also, this would be a good motivation to invest into moving the type checks for
known functions onto the caller side, and eliding them completely if the
variable is unmodified. By now we have knowledge when variables can definitely
not leak (are no references, no varvars or extract etc. are used) and check
whether and what they are being assigned during the lifetime of the function.
In fact, using "int & < 10 & > 1" would give pretty strong bounds for opcaches
data flow analysis to use too, giving much better hints at what integers will
never be promoted to float, reducing the amount of guards necessary in JIT for
example. An int which never can be < 0 for example saves a bounds check in one
direction as well when working with packed arrays.
I.e. depending on the patterns and their integration into opcache quite a bit
of potential could be unlocked.
But yes, you can always find worst case performances.
> 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.
Why would it be particularly hard? We already have dedicated types APIs for
stuff like type intersection and union. I don't think there would be a lot of
impact.
> 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.
>From the perspective of an autoloader, a type name is just like any other
>class name.
This is more composers problem to solve (they possibly could include a
per-namespace fallback to a default.php or something, where you'd define all
types of a namespace in).
We should have type names eventually, but I consider them separate from the
basic pattern feature. Should be done, but separate RFC with its own concerns,
and I also suppose a pretty simple RFC actually!
> 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.
I don't think we would need to include binding in a first version of this.
> 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?)
I also don't think that pattern matching needs particular changes to fit this.
The syntax of pattern matching is pretty fine and could be just 1:1 translated
to function args.
> --Larry Garfield
Thanks,
Bob
