`Equals<T, U>` used inside of generic type gets simplified to `false` immediately if only `T` or only `U` depends on a type variable

[carljohnsonnewhampshire-hue]

🔎 Search Terms

"type identity check", "type equality check", "conditional type elimination", "generic simplification", "dependent conditional types", "eager evaluation", "deferred evaluation", "conditional type simplification", "deferred conditional type evaluation", "dependent conditional type", "generic function", "generic function with conditional return type", "type equality check", "dependent types", "dependent return type"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about "common bugs that aren't bugs"

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/KYDwDg9gTgLgBDAnmYcCiBHArgQwDYDOAPACoA0cAqgHxwC8AUHHABREAa1LAlPbe3FAxgAOwAmBOCTgB+OAEY4ALjgAmXkNES4HLrzr9BIYeMmVZC5WqbMLMKFmA3mKgGb4CwANwMGSFHAASsBgUBDyRABqtHTo2B5EANqRALoUifIp1L7+qMGhEKpRMXCJySkpRibaiQCWIq7AUHAA8pVymLiERC3pmbQqIsAAbk0+DGLAAMZ4OFCow3NwBAAWEFh4YgBCwCQOwPIq+WER8tQ+kzNzC0ur65s7e46qRyFhRWfjl7PzcIvNdw222AADEPAdXgUIjgRIhzhNpj8bgC1kCdmDCMAXkE3oUiDC4eNAQ9dvtFLF7I4fMTgU8sfQEPsiaiSRjPOS4O5MdSWcC2fTYlzPD4gA

💻 Code

export type Equals<T, U> =
  (<X>() => X extends T ? 1 : 2) extends <X>() => X extends U ? 1 : 2
    ? true
    : false;

type Repro1<V> = Equals<[V], [1]>

type Repro2<V> = [[V]] extends [infer O] ? Equals<O, [1]> : never;

declare var shouldBeTrue1: Repro1<1>;
declare var shouldBeTrue2: Repro2<1>;

declare var shouldBeFalse1: Repro1<any>;
declare var shouldBeFalse2: Repro2<any>;

shouldBeTrue1 = true;
shouldBeTrue2 = true;

shouldBeFalse1 = false;
shouldBeFalse2 = false;

🙁 Actual behavior

true is not assignable to shouldBeTrue1 and shouldBeTrue2 as their type is false.

🙂 Expected behavior

true should be assignable to shouldBeTrue1 and shouldBeTrue2

Additional information about the issue

No response

[carljohnsonnewhampshire-hue]

I've found two workarounds so far for this. First one is ensuring that both type arguments to Equals are dependent on type variables, for example:

type Workaround1<V> = Equals<[V], [V extends any ? 1 : never]>  // fixes the issue

type Workaround2<V, _X = [1]> = Equals<[V], _X>  // also fixes the issue

and the second one is changing Equals type like this:

export type Equals<T, U> = T extends U  // Adding T extends U condition also fixes the issue
  ? (<X>() => X extends T ? 1 : 2) extends <X>() => X extends U ? 1 : 2
    ? true
    : false
  : false;

[RyanCavanaugh]

See #56721; you should not use this definition of Equals unless you fully understand its caveats.

[carljohnsonnewhampshire-hue]

I do fully understand its caveats. But this is clearly a bug, don't you agree? Also, I've read the issue you linked, and you're asking there "where are people getting this definition of Equals from?" and suggesting to use [T] extends [U] ? [U] extends [T] check to check for equality, as if it's a bad thing to want to check that types are actually identical or at least equivalent -- it is completely valid and common use case to want to write robust type assertions of an API in a unit test or whatnot, and this approach is one of the very few tricks to be able to actually do that.

[carljohnsonnewhampshire-hue]

Also, my issue is not related to #56721 AT ALL. I apologize if I come off as rude, but did you read my issue? I know exactly why the issue in that person's report happens, that's clear as day, and the issue I'm posting here is completely unrelated to it, not in one thing is it similar, at all. My impression is that you didn't read my issue at all but just saw the use of <T>() => T extends A ? 1 : 2 and immediately brushed it off and marked it as duplicate. Why? Please read the issue. And at this point everyone's aware of this "trick", people rely on it, libraries depend on it, it's used all over typescript's own test suite, so pretending like it's some hidden internal implementation detail is just not a way forward with this, because it isn't - it's not a bug or a quirk or unintended side effect, it's a clearly defined logic in the checker for comparing conditional types, it is expected for this to be observable, it is a well-established and relied upon logic.

[RyanCavanaugh]

We've written about this Equals definition pretty extensively over the years. It can and does return false for some situations where true is "expected". I added a FAQ entry that goes into a bit: https://github.com/Microsoft/TypeScript/wiki/FAQ#the-equals-type-is-implementation-defined

I do fully understand its caveats.

I'm really not sure that you do? Two spellings of "the same" type (1 in this case) might or might not have identical type identity. What makes you think this isn't a manifestation of these caveats?

[carljohnsonnewhampshire-hue]

Hmm, thanks for sending that FAQ section link, I didn't know about it, it would be useful if the FAQ page had some sort of TOC at the top as the page is really long and it's unlikely for anyone submitting a bug report to read through all of it and discover this or the other section you know?

Anyway, thanks for answering. Okay, so the fact that it's clearly documented (at least in this FAQ section) as not well-defined and as an implementation detail clears things up a bit, I got it. Still though, I think by now pretty much anyone who've come across this conditional type knows about intersections not being equal to equivalent records per this Equals definition etc etc, and still libraries use it extensively and provide various wrappers on top of it to make it behave more as "equivalence" check than true "identity" check e.g. .branded in expectTypeOf() in vitest ([https://vitest.dev/api/expect-typeof.html#branded]).
So I guess my question is do you agree that this peculiar type now falls into "Hyrum's Law" territory in that implementation-detail or not, the ecosystem and people largely depend on it now and it is valid to rely on it and use it. I understand that as it's explained (in that hard to find FAQ section) to be an implementation detail no one can ask for anything related to it, fine; but still, the issue I've posted seems reasonable, I mean not a complete nonsense, right?

[mkantor]

@carljohnsonnewhampshire-hue what's your use case for this type? As stated in that FAQ entry, "type equality" is not a concept that exists in TypeScript's type system, so perhaps what you really want is something else (mutual assignability?).

[carljohnsonnewhampshire-hue]

@mkantor, what I want is to be able to have strong type assertions in my unit tests that types are identical without any unsoundness like { a: 1 } and { readonly a : 1 } being mutually assignable. I'll stick to the augmented Equals definition (the one with additional [T] extends [U] check) for now, thanks.