Types `number` and explicitly constrained `T extends unknown` shouldn't be comparable

[DanielRosenwasser]

const num = 1;
function check<T extends unknown>(x: T) {
  return x === num;
}
check(num);

Expected: Error: This condition will always return 'false' since the types 'T' and '1' have no overlap.
Actual: No error.

Contrast this with the following example from #32768.

const num = 1;
function check<T>(x: T) {
  return x === num;
}
check(num);

[AnyhowStep]

I would expect both the explicit and implicit extends unknown to be comparable to 1.

It's sound that if x === num, then you can narrow x to 1.
Is there a reason to not want to allow that behaviour?

---

If it's disallowed, does that mean the code would then have to be,

const num = 1;
function check<T extends unknown>(x: T) {
  return typeof x === "number" && x === num;
}
check(num);

to work?

[ilogico]

I suppose the following shouldn't be allowed either:

function check<T extends string | number>(x: T) {
  return x === 1;
}

The problem is not specific to extends unknown.

[davidje13]

This seems backwards to me; it's clear that "This condition will always return 'false'" is a lie. In the example, it will return true!

The current <T extends unknown> behaviour is the correct one. The <T> behaviour is wrong.

[jack-williams]

@davidje13 The problem with that approach is that any two unrelated type parameters become comparable, which is a bug in many cases.

I'll probably wait on the design meeting before looking more into this --- it's not quite clear what the new behaviour should be. The code-path I linked on the other issue is the one influencing the unconstrained case, which means that the implicit constraint of T in <T> is the empty object type.

• Does this mean that the new constraint of <T extends unknown> should be {} to bring them into parity? That seems wrong.
• Does that mean we ignore the unknown constraint in <T extends unknown> and the implicit {} constraint in <T>? This would be a breaking change in both directions (but maybe reasonable?).
• Or is there a special case for <T extends unknown> where we ignore the constraint completely, but then <T extends unknown> would be different to <T>, with the former being more conservative.

There may be more options I don't know about.

[DanielRosenwasser]

For what it's worth, there was a suggestion that "any two type parameters should be strictly rejected when comparing them", but the fact that that wouldn't cover keyof T being comparable to T is part of why that's not sufficient (because it's still surprising).

[davidje13]

any two unrelated type parameters become comparable, which is a bug in many cases

It feels like you're trying to shoehorn code quality checks into a type system. If you make it behave this way, you will be breaking the correctness of the type checking and you'll be chasing weird edge cases throughout the system (not to mention forcing the use of any upon anybody who actually needs to perform these kinds of comparison). While this change may find the specific bad style of comparing 2 different generic variables, it is actually wrong from a types perspective.

To be clear, it is obvious that function isSame<T, U>(t: T, u: U) { return t === u; } can return true or false. The comparison is legitimate, and has potential value. From the type system's perspective, this is perfectly valid code (although, apparently, not right now unless you explicitly add extends unknown).

Of course, TypeScript should catch function foo<T, U>(t: T, u: U): U { return t; }. Because although T's unknown does overlap with U's unknown, neither extends the other. Comparison will always be possible between them, but assignment is not possible in either direction without further type narrowing. Note that when using extends unknown, the type system is already able to achieve this correctly.

[jack-williams]

It feels like you're trying to shoehorn code quality checks into a type system. If you make it behave this way, you will be breaking the correctness of the type checking and you'll be chasing weird edge cases throughout the system (not to mention forcing the use of any upon anybody who actually needs to perform these kinds of comparison).

I don't know what breaking the correctness of type checking means in this context, but it would not force users to use any. All values are comparable at type unknown.

function compare(x: unknown, y: unknown) {
    return x === y;
}

function test<T,U>(t: T, u: U) {
    if (compare(t,u)) {
        
    }
}

While this change may find the specific bad style of comparing 2 different generic variables, it is actually wrong from a types perspective.

There are plenty of languages that do not let you compare arbitrary generic types, so I'm not sure what you mean by 'wrong'.

[davidje13]

@jack-williams see the original issue #32768 for my actual use-case which kicked this off.

There's clearly some miscommunication here because both of us think our view is the only possible logical interpretation. So to maybe clarify my perspective:

function compare<T, U>(t: T, u: U) {
  return t === u;
}

What we know before the comparison:

• typeof t ⊆ T ⊆ unknown
• typeof u ⊆ U ⊆ unknown

What we additionally know if the comparison is true:

• typeof t ⊆ typeof u
• typeof u ⊆ typeof t
• i.e. typeof t = typeof u

What we additionally know if the comparison is false:

• nothing

Clearly the false case is possible, and I don't think that's disputed.

The true case has the following combined type assertions:

• typeof t ⊆ T ⊆ unknown
• typeof u ⊆ U ⊆ unknown
• typeof t = typeof u

Which resolves to saying that ∃ S : S ⊆ (T ∩ U), where S ≠ ∅ (above, S would be typeof t or typeof u). Or more simply, (T ∩ U) ≠ ∅

At this point, we do not have enough information to formally decide this one way or the other; (T ∩ U) might be the empty set, or it might not. Therefore, this branch might be possible, or might not. The undecidability means that we cannot possibly claim it "will always return 'false'", though that in itself could be fixed by just changing the error wording.

What I mean by "breaking the correctness of the type checking" is exactly this; if we choose to assume undecidable states cannot happen, we are no-longer modelling how the program can actually operate (i.e. the real behaviour it may exhibit). The only way to continue modelling how the program can actually operate is by assuming that undecidable states can happen, until we have enough information to prove that they cannot happen (at which point they cease being undecidable).

To hammer the point home, consider the closely related code:

function compare(t: string | number, u: string | number) {
  return t === u;
}

Once again, typeof t and typeof u might have no overlap (i.e. one may be a string and the other a number), but clearly we want to allow the comparison (and currently do allow it). The only difference here is the level of indirection; in this example the uncertainty is with (typeof t ∩ typeof u) ≟ ∅, whereas before it was a level higher. Going a level deeper again, we start looking at literal types and find ourselves defining the === operator itself as (typeof t ∩ typeof u) ≠ ∅ (i.e. it is defined as a runtime test for the region of undecidability). Doing differently at higher levels of indirection introduces an asymmetry in the type system.

[RyanCavanaugh]

Useful, consistent, correct: Pick any two 😅

[RyanCavanaugh]

To be clear, it is obvious that function isSame<T, U>(t: T, u: U) { return t === u; } can return true or false. The comparison is legitimate, and has potential value.

An additional desirable symmetry is that a generic function should be type checked such that an error is issued if any concrete version of the function would have errored. In this case, we can easily construct an erroring instatiation isSame<string, number>:

function isSame(t: string, u: number) { return t === u; }

Moreover, you have many options when writing isSame to decide how you want both the caller and the implementation to be checked. If you want to take any two values and compare them freely in the body, unknown, unknown is the proper signature. Choosing to write this function with type parameters should imply some other behavior because providing different behavior is why different syntax exists.

[AnyhowStep]

error is issued if any concrete version of the function would have errored.

That's actually a really good argument. And now that I'm thinking about it that way, I'm having trouble coming up with an example where T extends unknown should allow arbitrary comparisons.

The original issue's intent would have been better written as,

const isNum = (v: unknown) => {
  if (typeof v !== 'number') throw new Error('Not a number');
  return v;
};
const isString = (v: unknown) => {
  if (typeof v !== 'string') throw new Error('Not a string');
  return v;
};

function makeExampleValue<T extends number|string>(validator: (v: unknown) => T): T {
  if (validator === isNum) return 42 as T;
  if (validator === isString) return 'something' as T;
  //Not really "unknown type".
  //More like, "unknown validator", since we're doing function comparisons
  throw new Error('unknown type');
}

Playground

[AnyhowStep]

Is the following behaviour intentional?

function check<T extends string|number> (t : T) {
    //This is okay, even though the instantiation of `T`
    //with `string` should make it non-comparable.
    //But becaues we are comparing a generic to a non-generic,
    //we seem to use the constraint `string|number`
    //and check if it is comparable to the non-generic `number`
    return t === 1;
}
function check2<T extends string|number, U extends number> (t : T, u : U) {
    //Doesn't work, though.
    //Cannot compare generic type `T` and `U`
    //because `T` could be `string`
    //and `U` could be `number`
    return t === u;
}

Playground

[Edit]
Changed U extends string|number to U extends number

---

[Edit]
The error message could be more descriptive,

This condition will always return 'false' since the types 'T' and 'U' have no overlap.

Should be more like,

This condition may always return 'false' since the types 'T' and 'U' may have no overlap.

Would be even better if it could say,

This condition may always return 'false' since the types 'T' and 'U' may have no overlap.

T may be string and U may be number, which do not overlap.