-
-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.safeExhaustive #218
Labels
enhancement
New feature or request
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
In my app that I'm working on, I love the developer experience of exhaustive checks, because they force me to handle all of the edge cases that I need. But too often I am encountering scenarios where something doesn't migrate quite right, my runtime type becomes slightly different than my compile time type, and then I get a production error and have to switch from
exhaustive
tootherwise
.Describe the solution you'd like
It would be extremely awesome if there was a safer alternative to .exhaustive that provided the same developer experience in typescript. To me this would look something like this:
Describe alternatives you've considered
Using .otherwise
In a perfect world (I know this is probably a bigger ask), it would be cool if we could create a customized instance of
match
so we wouldn't have to dump in a callback every time or something like that. But I imagine that's a much bigger lift than just building a.safeExhaustive
methodThe text was updated successfully, but these errors were encountered: