Suggestion: Type guard generic types

[dsherret]

Would it be good to have type guarding on generic types? Or was this decided against?

Example 1

class Parent {
    prop1: string;
}

class Child extends Parent {
    childProp: string;
}

var t: Parent = new Child();

if (t instanceof Child) {
    t.childProp; // no error
}

function myFunction<T extends Parent>(item: T) {
    if (item instanceof Child) {
        item.childProp; // error
    }
}

I realize this example could be rewritten without generics. It's just an example :)

Example 2

Here's a scenario I came across when creating a wrapper class:

interface NedbItem {
    _id: string;
}

function isNedbItem(item: any): item is NedbItem {
    return item != null && typeof item._id === "string";
}

class DatabaseWrapper<T> {
    getItems() {
        const itemsFromDatabase: T[] = .....;

        itemsFromDatabase.forEach(i => this.stripNedbID(i));

        return itemsFromDatabase;
    }

    private stripNedbID(item: T) {
        if (isNedbItem(item))
        {
            delete item._id; // error, _id does not exist on T
        }
    }
}

Maybe a generic type with no constraint should be treated like an any type in this case? (Once type guards are fixed for any types -- See #4432)

This suggestion is probably very low on the priority scale.

I couldn't find this issue discussed elsewhere so sorry if it was.

[dsherret]

Just thinking about this a bit more. I guess this is not allowed for the same reason that this is not allowed:

function myFunction<T>(item: T) {
    const s = item as string; // error, neither T nor string is assignable to the other
}

I guess it does make sense to not allow this the more I think about it and it won't be needed in most scenarios.

I'm closing this issue.

[ziahamza]

There are still valid cases where this can be helpful, especially when generic type extends from a union type. E.g

class Cat {    }
class Dog {  }
class Node<T extends Cat | Dog> {
     data: T = null
     print() {
          if (this.data instanceof Dog) {
                // this.data now has the type Dog inside the block
          }
     }
} 

But the example doesnt seem to work today as typescript does not specialise the generic type even if it is a subset of the type it extends from

[mhegazy]

there is another problem in the use of this.data; type guards do not work on property look ups only variables. that is tracked by #1260

[RyanCavanaugh]

Accepting PRs.

The root cause here comes from two factors.

First is that given a (constrained) generic type parameter T extends U, we don't consider T to be assignable from a subtype of U. That rule is correct - it would be unsound to let you write code like this:

function clone<T extends Animal>(x: T) {
  return new Dog(); // Unsafe: Dog is subtype of Animal, but is not a subtype of T
}
clone(new Cat()); // Example invocation of other subtype

Second is that a type guard on an expression of type W to type V only succeeds if V is assignable to W. That rule is also correct -- typeguarding guarding a Cat with isDog should not succeed.

The rules do not combine favorably in the case of generics, though. We believe the correct fix is to take the apparent type of the generic type parameter when performing the assignability check in the second rule.