Exhaustiveness checking?

Very cool library, thanks for creating it! Would it be possible to force exhaustiveness checking for union types? For example:

function getSomeString(unionType:  "foo" | "bar"): string{
     return match(unionType).with("foo", () => `A string result, but we won't check for "bar"!`).run()
}

This will not be a compile time error. If you write it as

function getSomeString(unionType:  "foo" | "bar"): string{
    if(unionType === "foo"){
        return `A string result, but we won't check for "bar"!`
    } 
}

You get TS2366: Function lacks ending return statement and return type does not include 'undefined' because TS can verify that you haven’t exhausted all of the cases.

It would be really nice if this library could take advantage of that. Failure to check all cases is a really easy bug to introduce!

[oguimbal]

That’s why case guards have been removed from Elm pattern matching, if I remember right 😃 And like you said, I guess that thats why they’re not enabled by default in Haskell … it can be quite confusing:

So I guess the only plausible way to go is just to disable it altogether in non trivial cases.

[gvergnaud]

👋 Hey, Thanks for your feedback!

I had a go at implementing exhaustive pattern matching when I first wrote this library (Here is the branch if you are curious). I agree having exhaustive patterns would be immensely useful, but it’s actually pretty hard to get right.

Support for when predicate doesn’t make our lives easier to implement it, because if the function given isn’t a Type Guard there is no way to narrow the return type to something more precise. I think that’s why exhaustive pattern matching isn’t turned on by default on languages like Haskell.

The second issue we face is with literal patterns. Consider this case:

const input: number
match(input)
    .with(2, () => 'two')
    .with(3, () => 'three')
    .run()

This block will not compile, because 2 's inferred type turns out to be number, so the second .with will have Exclude<number, number> which evaluates to never as narrowed input type and which isn’t compatible with a 3 pattern. Of course you could do .with(2 as const, ...) to mitigate this issue, but the fact that the default behavior is incorrect and confusing discouraged me to actually push this experiment to the main branch. I looked for ways to force Typescript to consider the first argument of .with as const or readonly by default, but I didn’t find a way to make it work.

Another approach we could have would be to make exhaustive patterns an opt-in behavior by extending the API surface of the library, as @oguimbal suggested in this PR but I’d like to make sure the proposed API makes sense before merging it.