Closed
Description
Search Terms
- Type System
- Equal
Suggestion
T1 == T2
Use Cases
TypeScript type system is highly functional.
Type level testing is required.
However, we can not easily check type equivalence.
I want a type-level equivalence operator there.
It is difficult for users to implement any when they enter.
I implemented it, but I felt it was difficult to judge the equivalence of types including any.
Examples
type A = number == string;// false
type B = 1 == 1;// true
type C = any == 1;// false
type D = 1 | 2 == 1;// false
type E = Head<[1,2,3]> == 1;// true(see:#24897)
type F = any == never;// false
type G = [any] == [number];// false
type H = {x:1}&{y:2} == {x:1,y:2}// true
function assertType<_T extends true>(){}
assertType<Head<[1,2,3]> == 1>();
assertType<Head<[1,2,3]> == 2>();// Type Error
Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript / JavaScript codeThis wouldn't change the runtime behavior of existing JavaScript codeThis could be implemented without emitting different JS based on the types of the expressionsThis isn't a runtime feature (e.g. new expression-level syntax)
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
AlCalzone commentedon Sep 11, 2018
Here's a working implementation:
The only problem is that
any
is "equal to" everything, exceptnever
.kgtkr commentedon Sep 11, 2018
@AlCalzone
I know that.(https://github.com/kgtkr/typepark/blob/master/src/test.ts)
There is a problem of not being able to judge any.
example:
DanielRosenwasser commentedon Sep 11, 2018
any
is not assignable tonever
, so you should be able to determine whether or not either side is exclusivelyany
.mattmccutchen commentedon Sep 15, 2018
Here's a solution that makes creative use of the assignability rule for conditional types, which requires that the types after
extends
be "identical" as that is defined by the checker:This passes all the tests from the initial description that I was able to run except H, which fails because the definition of "identical" doesn't allow an intersection type to be identical to an object type with the same properties. (I wasn't able to run test E because I don't have the definition of
Head
.)kgtkr commentedon Sep 22, 2018
Thank you
There was a way
aleclarson commentedon Apr 11, 2019
The best solution I have to date: spec.ts
Examples
jituanlin commentedon Jul 9, 2019
It work, but how?
Could you provide more explanation?
I try to explain it though by
Typescript's bivariant behavior
or something else.But I failed, help, pls.
fatcerberus commentedon Jul 12, 2019
@jituanlin AFAIK it relies on conditional types being deferred when
T
is not known. Assignability of deferred conditional types relies on an internalisTypeIdenticalTo
check, which is only true for two conditional types if:weakish commentedon Dec 22, 2019
@AlCalzone It seems that function overloads do not work.
@mattmccutchen
Function overloads works:
But function type intersection does not work:
AnyhowStep commentedon Mar 10, 2020
Can we re-open this or something? Because there isn't a way =(
AnyhowStep commentedon Jun 15, 2020
#37314 (comment)
Seems like it's fixed in
master
, with TS 4.0 as the milestone.So, this doesn't need to be re-opened, I suppose. I forgot to link to that comment sooner, my bad.
127 remaining items