Repository navigation
Include const enum members as possible literal types #7642
Description
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;
}
Activity
DanielRosenwasser commentedon Mar 24, 2016
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. Mohamed Hegazy (@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 commentedon Mar 24, 2016
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 commentedon Mar 26, 2016
Daniel Rosenwasser (@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 commentedon Jun 29, 2016
With #9407 const enum members become literal types.
ahejlsberg commentedon Jul 28, 2016
#9407 has been merged, closing this issue.