Repository navigation
Include const enum members as possible literal types #7642
Description
Activity
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.
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.
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.)
With #9407 const enum members become literal types.
Reacted by Claudia Meadows#9407 has been merged, closing this issue.
- locked and limited conversation to collaborators
on Jun 19, 2018
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.