On Tue, Jun 16, 2026, 1:31 AM Sarina Corrigan <[email protected]> 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.
