Skip to content
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

Closed
zpdDG4gta8XKpMCd opened this issue Dec 18, 2015 · 10 comments
Closed

consider allowing exhaustive switch statement #6155

zpdDG4gta8XKpMCd opened this issue Dec 18, 2015 · 10 comments
Labels
Fixed A PR has been merged for this issue Suggestion An idea for TypeScript

Comments

@zpdDG4gta8XKpMCd
Copy link

type foo = 'hey' | 'nay';
let value : foo = 'hey';
switch (value) {
    case 'hey': doThis(); break;
    case 'nay': doThat(); break;
    default: void; // <-- syntax TBD that indicates: 1. no other than known options are allowed 2. all known options must be considered
}
@zpdDG4gta8XKpMCd
Copy link
Author

(it's up to the developer to take the responsibility for possible contract violations at runtime)

@weswigham
Copy link
Member

The default branch in your example can be triggered when value is undefined or null as both let value : foo = null; and let value : foo = undefined; are valid for type foo.

@zpdDG4gta8XKpMCd
Copy link
Author

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

@zpdDG4gta8XKpMCd
Copy link
Author

slippery moment here is that the undefined is just a variable, not a literal, but hey, why would you want to mess with it? anyway the emitter can take care of it:

case void undefined: doSomethingElse(); break;

By the way, why wouldn't TypeScript stop this nonsense and straiten things up by proclaiming undefined a literal and thus preventing it from being assigned?

@zpdDG4gta8XKpMCd
Copy link
Author

On top of that please admit that Undefined is a real type that can be referenced as well as Null. It's never a good idea to depart from what the real world is (I mean JavaScript here) by trying to model it using wrong entities (void type in TypeScript).

@RyanCavanaugh
Copy link
Member

TypeScript should stop this nonsense and straiten things up by proclaiming undefined a literal and thus prevent it from being assigned.

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.

@mhegazy mhegazy added Suggestion An idea for TypeScript In Discussion Not yet reached consensus labels Feb 19, 2016
@mhegazy
Copy link
Contributor

mhegazy commented Feb 19, 2016

with #7140 in place we should be able to make better decisions here.

@zpdDG4gta8XKpMCd
Copy link
Author

I am super excited to welcome non-nullables, but exhaustive switches are a different beast isn't it?

@ahejlsberg
Copy link
Member

Checking for exhaustive switch statements is now possible with #9407.

@zpdDG4gta8XKpMCd
Copy link
Author

best day ever! thanks a bunch

@mhegazy mhegazy added Fixed A PR has been merged for this issue and removed In Discussion Not yet reached consensus labels Jun 29, 2016
@mhegazy mhegazy added this to the TypeScript 2.0 milestone Jun 29, 2016
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Fixed A PR has been merged for this issue Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

5 participants