Typescript forbids safety checks that check equality of values with different generic types

[UppaJung]

TypeScript Version: 2.4.2

When a function is passed two arguments of two different generic types, there exists the possibility that the two generic types are in fact the same type and that the two values are the same value. A function should be able to test for this case and handle it appropriately, especially when ensuring the two values are different is essential to a safety condition. However, typescript forbids us from making this comparison.

Code

// 'Operator '===' cannot be applied to types 'T' and 'U'.'
function test<T, U>(a: T, b: U): void {
  if (a === b) {
    // The caller set T and U to the same type and 'a' and 'b' to the same value.
    // Take apprpriate action
  }
}

Expected behavior:

Allow the comparison, perhaps with a TSLint warning asking me if I'm sure I want to do this.

Actual behavior:

'Operator '===' cannot be applied to types 'T' and 'U'.'

Forcing me to make workaround of

// Workaround using the three-letter profanity eschewed by all righteous TypeScript programmers
function test<T, U>(a: T, b: U): void {
  if (a === (b as any)) {
    // The caller set T and U to the same type and 'a' and 'b' to the same value.
    // Take apprpriate action
  }
}

[DanielRosenwasser]

This is something we should consider. I would say that the proposed change is the following:

*S* is ***comparable to*** a type *T*, and *T* is ***comparable from*** *S*, if one of the following is true:
  * ...
  * *S* is a type parameter and the constraint of *S* is comparable to *T*.
+ * *T* is a type parameter and *S* is comparable to the constraint of *T*.

[gcnew]

Please no. There is a reason why the saying "comparing apples and oranges" exists. T and U are different types and comparison is meaningless in the general case. Casting to any is a sufficient workaround, IMHO.

[kitsonk]

Yeah, I agree, unless there is some sort of type relationship between the two, the type system is doing what a type system does, letting you know you might have a logic error, unless you are more specific.

This should be valid though, but isn't:

interface Foo {
    foo: string;
}

interface Bar extends Foo {
    bar?: string;
}

function test<T extends Foo, U extends Bar>(a: T, b: U) {
    if (a === b) { // Operator '===' cannot be applied to types 'T' and 'U'.
        // do something
    }
}

[gcnew]

I don't think it should be valid. The real type of equality is <T>(x: T, y: T) => boolean. I.e. only arguments of the same type should be compared. That's the reason why in Java the first thing you check is whether the classes of the arguments are the same. If the intention is to check Foo's descendants, then test(a: Foo, b: Foo) would be a better signature.

[gcnew]

Related: #17404

[kitsonk]

That's the reason why in Java the first thing you check is whether the classes of the arguments are the same.

TypeScript is not a nominal typing system. I know you know that. So comparisons to Java are grounded in folly. Types are assignable based on their structure, not their ancestry, so comparisons of two related types can end up with a variable having two different types but still be the same reference, something that is impossible in Java.

True though that test(a: Foo, b: Foo) is better solution to the particular problem here, but to disallow strict equality of references when the types are related would seem contrary to a structural type system to me.

[gcnew]

In T extends Foo, U extends Bar, you clearly know that U has one property more. If it didn't, they'd be the same type (maybe with different aliases)! But in general, T can be any descendant, including ones not following the Bar line, and in that occasion you'd be comparing apples to oranges.

Another way to look at it is that bounds provide a minimal interface, but the concrete types are "some types" that we know nothing about. On the logical level we shouldn't be comparing two unknown things. And indeed, most of the time it makes no sense.

Do we really want to let the plethora of badly typed programs, for the rare single valid one? E.g. in the simplest case of number:

function testNumber<T extends number, U extends number>(x: T, y: U) {
    return x === y;
}

will always return false unless T and U are actually the same literal type.

PS: Please note that every type parameter can be weakened to the lower bound of {} | null | undefined. That means that any two parameters will be equitable, provided they don't have explicit incompatible bounds.

[kitsonk]

function testNumber<T extends number, U extends number>(x: T, y: U) {
    return x === y;
}

will always return false unless T and U are actually the same literal type.

Which the can be, quite easily, so why disallow the comparison? In that case it is entirely valid and entirely sound. Allowing the comparison doesn't make anything less sound, and it is arguable that it is statically identifying an error.

This is totally valid:

function testNumber(x: number, y: number) {
    return x === y;
}

There is a big difference in comparing value/primitive based variables and non-primative/references. The type system doesn't make a huge distinction against them, but there are certainly cases where it is valid to strictly compare two references to see if they are in fact the same object, which is a different operation than comparing if two primitives are the same value.

TypeScript in this case is asserting something is unsound when it actually doesn't know if it is unsound or not. The TypeScript team generally err on the side of pragmatic about uncertainty, only getting in the way when it is certain constructs are errors. I would see an argument if it were some sort of assignment, but a comparison, worst case is unnecessary or illogical versus being wrong and in some cases is totally valid.

[simonbuchan]

I'm a little confused about "unsound" here: JS doesn't let you override operators, so there's zero chance of a === b causing an error when run, or causing coercion like (all the?) other operatorrs. The only soundness errors TS could give here would be where the types are exclusive: (x: string, y: number) => x === y should probably error with something like 'string' and 'number' can never be equal.

If you wanted, you could make a pragmaticness argument though: (x: { foo: string }, y: { bar: number }) => x === y seems like it should be an error, but { foo: "evil", bar: 666 } is assignable to both x and y.

I would prefer it to be permissive here, but I don't feel too strongly.

[RyanCavanaugh]

I have a hard time with this. It's tempting to allow any comparison with ===, but it's very easy to write code like

if (x.name === entry.getName) {
  // oops, forgot to call, this code is now unreachable
}

or

if (input.value === 0) { // forgot to use parseInt or unary+

With no information about what T and U are, it seems foolish to allow comparisons between them without some indication from the developer that they intend to do this. What about code like this, where you have two completely isolated domains of values and want help keeping them separate?

function doMap<K, V>(x: MappingThing<K, V>) {
  for (const k of x.keys()) {
    const v = x.getValue(k);
    if (k === v) { // wat, why is this allowed? keys aren't values!
      // ...
    }
  }
}

[simonbuchan]

Perhaps must share a not-top type? Or one is assignable to the other?