Repository navigation
T extends unknown is observably-different from an unconstrained T #61242
Description
🔎 Search Terms
"extends unknown" "type parameter" "generic" "conditional type" "keyof" "string" "assignable"
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about type parameter constraints
⏯ Playground Link
💻 Code
type Example<T> = T extends {} ? keyof T : string
const unknownConstraint = <T extends unknown>(x: Example<T>): string => x
const noConstraint = <T>(x: Example<T>): string => x
// ^
// Type 'string | number | symbol' is not assignable to type 'string'.
// Type 'number' is not assignable to type 'string'.🙁 Actual behavior
The T extends unknown version behaves differently from the unconstrained version.
🙂 Expected behavior
The two versions should have the same behavior, probably both being rejected since code like this is unsafe:
const key = Symbol()
const bad = unknownConstraint<{ [key]: unknown }>(key)
bad.toUpperCase() // boomAdditional information about the issue
I was asked about this and eventually narrowed down the behavior to the example above.
#61203 is also possibly related?
Activity
LukeAbby commentedon Feb 21, 2025
My theory is that this is for backwards compatibility when symbol keys were being added.
You can also get this behavior with any type whenever the apparent type of
keyof Tdoes NOT extendsymbol | number.For example:
Notably this means that
T extends {}actually errors. This furthers my hypothesis that the test isextends symbol | number ? error : do nothingbecausenevertechnically extendssymbol | number. To further thisT extends {} | 1doesn't error.This does still leave
unknownas a second special case though.mkantor commentedon Feb 21, 2025
#56652 seems possibly-relevant as well.
RyanCavanaugh commentedon Mar 24, 2025
This is indeed a back-compat allowance; for a long time the default constraint was closer to
{}thanunknown(admittedly really neither). Hopefully we can eventually remove it but for now, unconstrained type parameters will sometimes appear toextend {}.typescript-bot commentedon Mar 27, 2025
This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.