Repository navigation
Problem with function types, <T>() => T extends X ? () : () #56721
Description
🔎 Search Terms
"function", "generic function"
🕗 Version & Regression Information
⏯ Playground Link
💻 Code
type Fn<X> = <T>() => T extends X ? 1 : 2
type Equals<X, Y> =
Fn<X> extends
Fn<Y> ? true : false
type A = Equals<{readonly a: 'A'}, {a: 'A'}>🙁 Actual behavior
type A should shows true.
🙂 Expected behavior
type A should be false.
It works well when the code is like this.
type Fn1<X> = <T>() => T extends X ? 1 : 2
type Fn2<X> = <T>() => T extends X ? 1 : 2
type Equals<X, Y> =
Fn1<X> extends
Fn2<Y> ? true : false
type A = Equals<{readonly a: 'A'}, {a: 'A'}>Additional information about the issue
No response
Activity
RyanCavanaugh commentedon Dec 11, 2023
Where are people getting this definition of
Equalsfrom??jcalz commentedon Dec 11, 2023
Probably originally from #27024 (comment) and then from sindresorhus/type-fest after that?
fatcerberus commentedon Dec 11, 2023
Context: This variant allows for distinguishing
anyfrom other types, which the more traditional variants ofEqualsdon’t.gs18004 commentedon Dec 12, 2023
I got it from https://github.com/type-challenges/type-challenges/blob/main/utils/index.d.ts
craigphicks commentedon Dec 13, 2023
@fatcerebus
What is amounts to is that the "correct" answer(s) to a type function "Equals(A,B)" depends on what it is being used for.
In particular, the types
any,never,unknown, and types described by an intersection&operator are corner cases that make Equals hard to define as a one-size-fits-all.Therefore exporting these intrinsic type functions
isAnyTypeisNeverTypeisUnknownTypeisIntersectionTypegetIntersectionTypeswould enable the users to handle the corner cases as they need, and simply apply
extendsto the remainder.fatcerberus commentedon Dec 13, 2023
Craig P Hicks (@craigphicks) That’s all true, but TS doesn’t add new pack-in utility types (intrinsic or otherwise) unless needed for declaration emit, so we have to work with what we have.
craigphicks commentedon Dec 14, 2023
If that in order not to pollute the global namespace? That's legit, but using a namespace (e.g.
ts.) to prefix all utilities would solve it.RyanCavanaugh commentedon Dec 14, 2023
The reason for not adding utility types is that whatever definition we choose will invariably not match what 30% (minimum) of people expect to happen w.r.t how they treat any, whether they distribute over unions, how they treat
unknown/void, whether the mapped forms are homomorphic, etc, leading to unending complaints that we picked the "wrong" definition of any given utility type.RyanCavanaugh commentedon Dec 14, 2023
It seems like we're using the strict subtype relation in one case, and regular assignability in the other. I don't even know which people are wanting with this definition of
Equals! It's perhaps possible to unify to the same relation but it's very difficult to predict what would break in that case.I'd really encourage everyone to just use something like
if they're not actively trying to probe the strangest corners of the type system 😵💫
fatcerberus commentedon Dec 15, 2023
The intent of this definition of
Equalsis ultimately to doisTypeIdenticalTo(X, Y); I believe the correct path for that is assignability (specifically, of deferred conditional types)