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

Include const enum members as possible literal types #7642

Closed
dead-claudia opened this issue Mar 22, 2016 · 5 comments
Closed

Include const enum members as possible literal types #7642

dead-claudia opened this issue Mar 22, 2016 · 5 comments
Labels
Domain: Literal Types Unit types including string literal types, numeric literal types, Boolean literals, null, undefined Fixed A PR has been merged for this issue Suggestion An idea for TypeScript

Comments

@dead-claudia
Copy link

String literals are already valid types now. This is very nice, but I would like the ability to use const enum members to the same effect. They don't change, they take a lot less memory, and they're faster to check. Plus, you have a clearer distinction of what the type is, where strings are pretty free-form at times.

// Now
type NodeType = "start" | "end"; // etc.
interface Node {
  type: NodeType;
}

interface StartNode {
  type: "start";
}

// What I'd like:
const enum NodeType {
  Start,
  End,
  // etc.
}

interface Node {
  type: NodeType;
}

interface StartNode {
  type: NodeType.Start;
}
@DanielRosenwasser DanielRosenwasser added Suggestion An idea for TypeScript Domain: Literal Types Unit types including string literal types, numeric literal types, Boolean literals, null, undefined Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. labels Mar 24, 2016
@DanielRosenwasser
Copy link
Member

Good idea to create an issue for this (following up from #1003 (comment) and #1003 (comment)).

I had an experimental version of this working with widening. I don't think that will actually work (due to problems surfacing from best-common type checking), so the way this would work is contextually typing. @mhegazy and I spoke offline about this the other day.

The point at which we decide to check for a contextual type is the question here. I don't necessarily want to resolve twice to try to grab an enum member type, but in practice, the perf impact from string literal type checking was not even much.

@weswigham
Copy link
Member

I have a version of this (enum member types) running with contextual typing built on top of my numeric literal PR, but I was having issues determining sane compatibility rules with numbers and numeric literal types without a separate comparable relationship. Now that strict null checking and the comparable relationship have been merged, I should update it to see how well it works.

@dead-claudia
Copy link
Author

@DanielRosenwasser What about memory? That's my other concern. Scalability and memory are why I filed this bug. (If you're dealing with a lot of ADT types, it helps.)

@ahejlsberg
Copy link
Member

With #9407 const enum members become literal types.

@ahejlsberg
Copy link
Member

#9407 has been merged, closing this issue.

@mhegazy mhegazy closed this as completed Aug 30, 2016
@mhegazy mhegazy added Fixed A PR has been merged for this issue and removed Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. labels Aug 30, 2016
@mhegazy mhegazy added this to the TypeScript 2.0.2 milestone Aug 30, 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
Domain: Literal Types Unit types including string literal types, numeric literal types, Boolean literals, null, undefined 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