-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Discriminate string or number literal from general type. #55095
Labels
Duplicate
An existing issue was already created
Comments
You'd need negated types for this to work properly, since this is a legal (but unsound) construction if this were allowed: const n: number = 200;
const m = { status: n, body: 42 };
const response: ApiResponse<{text: string}> = m;
if (response.status === 200) {
response.body.text // claimed as string, but is undefined |
Ah yeah, i guess that's basically what I was getting at with Seems really useful, but probably a pretty big amount of work to implement. Thanks for the help! |
This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Suggestion
π Search Terms
β Viability Checklist
My suggestion meets these guidelines:
β Suggestion
π Motivating Example
I want to be able to write code such as
Fundamentally, this seems like the type checker needs to evaluate literal types before more general types.
I've also tried using
Exclude
but that doesnt help for obvious reasons.This is also useful for strings and string literals too, e.g.
{type: "a", a: number} | {type: string, value: unknown}
π» Use Cases
I think its surprisingly common that there are well known types we can use to narrow down a value, while there is still a large unknown amount of types that we aren't aware of an perhaps don't even care about.
The variety of http responses I could get is much larger than I can properly type (unfortunately), but the same can be said for progressively typing a large library. Perhaps I only care about a few different object types, but I still want there to be a catch all for the things I haven't typed yet and might run into...
The text was updated successfully, but these errors were encountered: