Re: [RFC] [Discussion] Literal Scalar Types

On Mon, Jun 15, 2026, at 7:44 PM, Seifeddine Gmati wrote: >> On Mon, Jun 15, 2026, 20:05 Seifeddine Gmati <azjezz@carthage.software> 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