Exhaustivity checking

[Risto-Stevcev]

Have an option that checks if the matching is exhaustive, and if it isn't then have it immediately throw an error that the matching isn't exhaustive.

[leonardiwagner]

@Risto-Stevcev What is your complain with the current way of only returning undefined instead throwing an error?

[Risto-Stevcev]

If the undefined value isn't handled or noticed then it will leak into other parts of the codebase and can lead to bugs that are hard to track down. You might actually think it's exhaustive and it isn't, and then much later on it could lead to nasty bugs. If it checks the cases and throws if it's not exhaustive then that won't happen. That's how haskell and elixir does it

[leonardiwagner]

@Risto-Stevcev yes indeed, at v0.x.x we was closer to these classical pattern matching specifications, however it wasn't well accepted since is too different from JS world. The decision to return undefined instead throwing error is to make familiar to JS programmers, which are used to check for undefined and prevent the mentioned bug prone behaviour.

I'll maintain that issue open for more people opine on that subject as well.

[paulojean]

I'm against to throw an error on this case, because of the friction it causes. In this line, I would rather return an option.

Also, the check that it is "exhaustive" would be to ensure that there is always a x => ... in the end (matching everything). Given the nature of dynamic typing of javascript (way different from haskell).

[Risto-Stevcev]

In Haskell you can define partial pattern matching. In those cases if you hit a case that isn't handled it'll immediately throw an error, the value won't silently propagate into your program. Same with Elixir, it immediately throws. Having it return an option will be less sound because of javascript's type system. What if that value gets used as a predicate? everything in javascript is truthy/falsy so it would break your business logic silently. The duck typing will create problems there, same with undefined. If it doesn't do exhaustivity checking then this is just syntactic sugar for a switch statement or if/else

[leonardiwagner]

Hey, I'm closing due inactivity, I truly understand the argument but we are aligned with JS community and JS "way of life" and we didn't get any complaints about that so far, any other news we reopen this issue, thanks for you all collaboration!

[Risto-Stevcev]

@leonardiwagner One other approach: you could make it optional, ie. a setting to make it 'stricter' and throw an exception, or to have the more lax/flexible version

[leonardiwagner]

@Risto-Stevcev sure, great idea!