When using generic parameters, the actual type is not assignable to an InstanceType on a constructor in an interface

[hochbergg]

I'm pretty sure this is a bug:
As there aren't generic namespaces, I'm trying to leverage constructors being passed for their types and not just their values.

I'm doing this using the InstanceType type, and it looks like there are cases where there is difference in behaviour between a direct value, a constructor, using attribute type lookup ([] on a type) and using typeof on a value.

TypeScript Version: Nightly, 3.8.3 (tested in playground)

Search Terms:
InstanceType
constructor

Code

class SomeClass {}

interface Factory<T> {
    make: { new(): T }; // This is a constructor for "T"
    value: T;
}

const factory: Factory<SomeClass> = { make: SomeClass, value: new SomeClass() };
const works1: SomeClass = new factory.make();
const works2: InstanceType<Factory<SomeClass>['make']> = new factory.make();
const works3: InstanceType<(typeof factory)['make']> = new factory.make();

function doesntWork<T, TFactory extends Factory<T>>(factory: TFactory): void {
    const works1: T = new factory.make();
    const valueWorks: TFactory['value'] = factory.value;

    const doesntWork2: InstanceType<TFactory['make']> = new factory.make();
    const doesntWork3: InstanceType<(typeof factory)['make']> = new factory.make();
    const doesWork: InstanceType<typeof factory.make> = new factory.make();
}

Expected behavior:
works1, valueWorks, doesntWork2, doesntWork2 and doesWork should all validate.

doesntWork2 and doesntWork3 should be assignable. (Similar ones work outside the function)
If my analysis is wrong, and they are not - the error message should be more clear.

Actual behavior:
works1, valueWorks and doesWork validate.
For doesntWork2: Type 'T' is not assignable to type 'InstanceType<TFactory["make"]>'
For doesntWork3: Type 'T' is not assignable to type 'InstanceType<TFactory["make"]>'

Playground Link:
https://www.typescriptlang.org/play/?ts=3.9.0-dev.20200328&ssl=1&ssc=1&pln=20&pc=2#code/MYGwhgzhAEDKD2BbApgYXFaBvAvgWAChCBLAOwBdkAnAMzGGWgDF7z4qBPAHgBUA+bIWjDoiMAGtkALmzRSyAO4AKAJQye0HAG5oAel3QeAC2IxT0MNGDxSEclQCuwNlWg120AEQ9PQkQDcwEAdpQy1CfCICa1tyN1Z2DhkWZ0SuBBR0SAgBAF5ZMUkZDLQMCAAaaEDg0PkFOCRS7NVNcOibO2gFdnEIAEZixqzMfLr41M4AOkLkVTaYzu6qXoAmGQBJWLBSBh4OAAdkLhSXbhLhnIBtAHIZ64BdPLlFcdPpiVmVeY64pd6AZg2Wx2yD2hy4SnIB2Q8Bor0SKhud0e0FGLzoEw470kc0IhBoDh25GINmgABN4MgIBQAOo9XiVHgnRLQZAAD0opDJMGZnF4fD4Sgxp3UvI4aiq8GIZMEBBEVh+XR6-XUqOe9WFiWxnza8oWcWqITpywgooSnBuhuQDzVmqmVrafmE+vJlOp5GN4jW0E2dm2u2hvDFSI+DyeYztWJmuLlIhdFKptJ6gJ9wID4Mh0Nh8M4iNuoZRaI15qjHxjesVCYgnqBfpBYKOUMO2cj2vD6JL2pjOCAA

Related Issues:
#34565 (Uses this, not a generic parameter)

[RyanCavanaugh]

Lookup types on generic type parameters are fully deferred - T["prop"] is effectively an opaque thing, and a conditional type like InstanceType can't match an infer T to it. In general this limitation doesn't produce many completeness deficits; attempts to assign some concrete value to a T["prop"] are unlikely to be sound against aliasing or manual type parameter specification.

There are only a few cases where it's provable from the outside that the assignment is safe - this is one of them - but we'd have to do a ton of special casing throughout the type system to make these work, and it's not common enough to justify the needed complexity.

[hochbergg]

Thanks for the quick response Ryan! The rationale makes total sense. (And I'll use the opportunity to say I ❤️ TS and thank you)

It may be helpful to have a better error message, as the current one makes it seem that the types are not assignable, where it is actually an TS implementation limitation, but probably not high priority as you say it's not a common case.

Two follow up questions:

1. I haven't opened many issues in OS projects. As this is a known design limitation, should I close the issue? Or keep open for future / people looking for open issues?

2. (This might be more a question for SO, and if it is feel free to let me know and I'll post there instead) Given lookups for generics are fully deferred, is there a way to have a "type namespace" which isn't fully deferred? I'll give an example:

interface MyTypeGroup<A,B keyof A,C> {
    aThing: Required<A>;
    bThing: Pick<A,B>;
    cThing: Parameters<C>;
}

// Then,
function func<M>(a: M['aThing'], b: M['bThing']) {
}

There purpose would be to be reduce the verbosity of template arguments required in situations with lots of inter-dependent generics. Currently I put together a type alias for each of the "aThing", "bThing", etc separately, but it ends up very verbose as I need to specify the template params for each (imagine its 8 params, some of which are complex).

I hope this make sense, and thank you.

[RyanCavanaugh]

Open/close state is up to the project maintainers to define. For us, "open" means "actionable work exists", and there's no actionable work here, so this will get automatically closed at some point in the future.

In this situation there's not much from the type system we can "see" to be able to identify a better error message, I think. For a lot of cases with generics we can check relative to the constraint, etc, but this is more of a counterfactual reasoning thing where if the type hadn't been deferred, then something else would have happened, but this requires sort of redoing the entire operation with different rules in place.

I'm not quite sure what you're trying to do with that example. An SO post with more examples would probably get useful answers pretty quickly from some of our stellar helpers out there - if not, ping me on Twitter @SeaRyanC and I'll go take a look.

[hochbergg]

Thanks.
My thinking RE the type system, is - its figuring out assignment can't happen, but it gives no reason. Going out on a limb here, In the underlying code where the fact that it is not assignable is discovered - could there be a way to share why?

Re the example, will take to SO. Thank you!

[MicahZoltu]

Another situation where I think this problem is rearing its head (for future readers):

const fruit = {
    apple: { color: () => 'red' as const },
    banana: { color: () => 'yellow' as const }
}
type Fruit = typeof fruit
type FruitKeys = keyof Fruit
function getFruit<T extends FruitKeys>(key: T): ReturnType<Fruit[T]['color']> {
// Type '"red" | "yellow"' is not assignable to type 'ReturnType<{ apple: { color: () => "red"; }; banana: { color: () => "yellow"; }; }[T]["color"]>'.
//   Type '"red"' is not assignable to type 'ReturnType<{ apple: { color: () => "red"; }; banana: { color: () => "yellow"; }; }[T]["color"]>'.
    return fruit[key].color()
}

It is useful to note that if we move the inference to the call site the problem goes away:

function getFruit<T extends FruitKeys>(key: T): Fruit[T]['color'] {
// Type '"red" | "yellow"' is not assignable to type 'ReturnType<{ apple: { color: () => "red"; }; banana: { color: () => "yellow"; }; }[T]["color"]>'.
//   Type '"red"' is not assignable to type 'ReturnType<{ apple: { color: () => "red"; }; banana: { color: () => "yellow"; }; }[T]["color"]>'.
    return fruit[key].color
}
getFruit('apple')()