-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
consider allowing exhaustive switch statement #6155
Comments
(it's up to the developer to take the responsibility for possible contract violations at runtime) |
The |
since we are going exhaustive here, and there is no way to ask the type system to prevent those 2 from popping up, let's require the developer to take care of them explicitly: case undefined: doSomethingElse(); break;
case null: void; // <-- instructing the compiler to chill |
slippery moment here is that the case void undefined: doSomethingElse(); break; By the way, why wouldn't TypeScript stop this nonsense and straiten things up by proclaiming |
On top of that please admit that |
This is already the case in strict mode. As for the null and undefined types, I think we want to keep their names "off limits" until we address nullability as a real language feature and understand the desired semantics there. |
with #7140 in place we should be able to make better decisions here. |
I am super excited to welcome non-nullables, but exhaustive switches are a different beast isn't it? |
Checking for exhaustive switch statements is now possible with #9407. |
best day ever! thanks a bunch |
The text was updated successfully, but these errors were encountered: