Proposal: new "invalid" type to indicate custom invalid states
## Proposal A new `invalid` type that is not assignable to or from any other types. This includes not being assignable to or from `any` or `never`. It probably shouldn't even be assignable to `invalid` itself if that is possible, although I doubt that one really matters. I'd additionally suggest that, unlike other types, `invalid | any` is not reduced to `any` and `invalid & never` is not reduced to `never`. The idea is to make sure that there is a compile error any time an `invalid` type is inferred or otherwise pops up in a users code. `invalid` types would come from conditional types to represent cases where the conditional type author either expects the case to never happen, or expects that it might happen but intentionally wants that case to cause a compile error indicating to the user that something is invalid with the code they wrote. The `invalid` type should also allow optionally passing an error message that would be displayed to the user when they encounter a compile error caused by the type that could give them a better idea of exactly what the problem is and how to fix it. ## Motivating Examples ### Allowing either `true` or `false` but not `boolean` - https://github.com/Microsoft/TypeScript/issues/23493#issuecomment-384369226 ```ts type XorBoolean<B extends boolean> = boolean extends B ? invalid<'only literal true or false allowed'> : boolean declare function acceptsXorBoolean<B extends boolean & XorBoolean<B>>(arg: B): void acceptsXorBoolean(true) // a
Posted by kpdonn on Apr 25, 2018, 8:23 PM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
Proposal: new "invalid" type to indicate custom invalid states
## Proposal A new `invalid` type that is not assignable to or from any other types. This includes not being assignable to or from `any` or `never`. It probably shouldn't even be assignable to `invalid` itself if that is possible, although I doubt that one really matters. I'd additionally suggest that, unlike other types, `invalid | any` is not reduced to `any` and `invalid & never` is not reduced to `never`. The idea is to make sure that there is a compile error any time an `invalid` type is inferred or otherwise pops up in a users code. `invalid` types would come from conditional types to represent cases where the conditional type author either expects the case to never happen, or expects that it might happen but intentionally wants that case to cause a compile error indicating to the user that something is invalid with the code they wrote. The `invalid` type should also allow optionally passing an error message that would be displayed to the user when they encounter a compile error caused by the type that could give them a better idea of exactly what the problem is and how to fix it. ## Motivating Examples ### Allowing either `true` or `false` but not `boolean` - https://github.com/Microsoft/TypeScript/issues/23493#issuecomment-384369226 ```ts type XorBoolean<B extends boolean> = boolean extends B ? invalid<'only literal true or false allowed'> : boolean declare function acceptsXorBoolean<B extends boolean & XorBoolean<B>>(arg: B): void acceptsXorBoolean(true) // a
Comments (0)
No comments yet. Start the discussion.