-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
After enum overhaul in TS 5.0, should we allow type assertion: number as Enum when number is not a valid enum? #54699
Comments
The entire purpose of type assertions is to allow assignments between related types that would otherwise be errors. |
Forgive me if my understanding is incorrect, but I dont think thats entirely true. I think the purpose of type assertions would be help the compiler where it wont have sufficient information to make a decision. For example, getElementById can return any type of Dom element, we can help the compiler to consider it a HTMLCanvasElement if we are confident that is what is going to be returned. Similarly for the case of enums, if we are evaluating a number and we are confident that it will evaluate to a valid enum, it should be okay to use "as", while in this case, it is obvious to the compiler that 3 is not a valid Color, so why even allow the conversion using "as". |
The enum could be used as a bitflag, in which case And fatcerberus is right, type assertions are an explicit way to override most type errors. That's why you can use a type assertion on object literal with missing or unmatching properties. If you're using a type assertion you always move outside of type safety. |
This also reminds me about #53400 (an issue about enums and comparability) - so I'd say that this is very much intended. |
This is a good point. I'm pretty sure I remember hearing that the TS codebase itself does stuff like |
There is also this thing at play here - that is considered to be OK today: const two = 2 as const as 3 Literal types are comparable within their domain regardless of actual values. |
I can see the argument that the example in the OP feels more like a sidecast (Cat -> Dog) than a downcast (Animal -> Dog), but that distinction is really a heuristic one rather than something with a strong theoretical grounding. The restrictions on the as operator are there to prevent total boneheaded mistakes ( |
This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
Bug Report
π Search Terms
π Version & Regression Information
This is a change in behavior since TS 5.0 as listed here https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html#enum-overhaul
β― Playground Link
Playground link with relevant code
π» Code
π Actual behavior
This line does not throw an error
π Expected behavior
The aim of the enum overhaul was to catch errors where illegal values are assigned to the enum. With "as" being still present, it is still possible to assign illegal values.
The text was updated successfully, but these errors were encountered: