TS2367: This condition will always return 'false' since the types 'Constructor<T>' and 'typeof Child' have no overlap.

[the-ress]

TypeScript Version: 3.2.0-dev.20181011

Search Terms: TS2367

Code

abstract class Base<T> {
    get Item(): T { return null }
}

class Child extends Base<Item> {
    constructor(public data: any) { super() }
}

interface Item { }
declare type Constructor<T> = new (data: any) => Base<T>

function func<T>(constructor: Constructor<T>): void {
    // TS2367: This condition will always return 'false' since the types 'Constructor<T>' and 'typeof Child' have no overlap.
    if (constructor === Child) {
        // do something
    }
    new constructor(null)
}

func(Child) // No errors

Expected behavior:

Compiles without errors.

Actual behavior:

test.ts:14:9 - error TS2367: This condition will always return 'false' since the types 'Constructor<T>' and 'typeof Child' have no overlap.

14     if (constructor === Child) {
           ~~~~~~~~~~~~~~~~~~~~~

Playground Link

Related Issues: #25642

[mattmccutchen]

The presence of an error is working as intended, as per the issue you cited (#25642), because neither constructor nor Child is assignable (or more technically, "comparable") to the other. To see the reasons for that, you can write out test assignments and look at the errors: Child isn't assignable to constructor because we don't know that the T chosen by the caller of func is Item, while constructor isn't assignable to Child because the instance type of Child has a data property and that of constructor doesn't.

The one thing we could do here is improve the error message to avoid the false claim that the condition will always return false. Along the lines of #25541, shall we say something like the following?

Comparison of expressions of types '{0}' and '{1}' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert one of the expressions to 'unknown' first.

[the-ress]

Thanks for the explanation. Yes, that error message would be more helpful.

[Manish-Giri]

Can I take this up?

[moccaplusplus]

Wait,

If Child satisfies function signature function func<T>(c: Constructor<T>): void without cast,
then it should also satisfy the === operator with Constructor<T> type on one side.

This is inconsistent behaviour.

It should either produce error in both cases or in none of them.

By the way, the old message was not ambiguous, the inconsistency was.

However there are even more inconsistencies:

1. If you only change Constructor type to:

declare type Constructor<T> = new (data: T) => Base<any>

then the comparison operator does NOT produce error.
(the same effect, of course, if you strip generics from this declaration)

2. Alternatively if you only make your Child class to be:

class Child extends Base<any> {
  constructor(public data: any) { super() }
}

then the comparison operator does NOT produce error.

So if the parametrized type is any (or unknown), then the explanation given by @mattmccutchen does not apply? ;)

Having said all above - I guess there is some deeper problem - so it should not marked as "good first issue").

[RyanCavanaugh]

@moccaplusplus === is only allowed between two operands if there is a "comparable" type relationship between them. This is similar to the check that determines if a type assertion is legal, with some extra special cases.

However, in this case, the compiler sees a comparison that looks like comparing a Horse to a Cat - both are Animals but it doesn't believe that any value inhabits both sides of the comparison (the existence of a hypothetical HorseCat notwithstanding).

The root cause of that, in turn, is that a type parameter behaves as if it were an arbitrary subtype of itself, because during an actual call the type parameter will be instantiated with some subtype but we can't say which -- this is why you can't return a Horse from <T extends Animal>(): T - a Horse is Animal, but T might be Cat.

[moccaplusplus]

@RyanCavanaugh It is incosistent. ;)

Proof:

Let's introduce function:

function constrEquals<T>(c1: Constructor<T>, c2: Constructor<T>): boolean {
  return c1 === c2;
}

then

function func<T>(constructor: Constructor<T>): void {
  constrEquals(constructor, Child); // No Error
  constructor === Child; // ERROR
}

[RyanCavanaugh]

It is incosistent.

Having different code behave differently is why some code produces errors and some doesn't. It'd be unfortunate if all inputs to the type system had to agree to all produce an error or all not produce an error.

Your example is similar to (horse as Animal) === Cat, which is legal by similar logic.

[moccaplusplus]

I just realized inconsistency was due to the fact that Item was an empty interface.

When it is not - then it's consistent:

function func<T>(constructor: Constructor<T>): void {
  constrEquals(constructor, Child); // ERROR
  constructor === Child; // ERROR
}

the call:
constrEquals(constructor, Child)
resolved to:
constructor as Constructor<Item> === Child as Constructor<Item>
which in turn, resolved to:
constructor as Constructor<{}> === Child as Constructor<{}>;
when the Item was empty interface,
which was OK.

adding some properties to Item interface made:
constructor as Constructor<Item>
to correctly produce an error.