Inference of generic constructor function return type.

[MicahZoltu]

TypeScript Version: 3.7.0-dev.20190817

Search Terms:
constructor type inference generic

Code

declare class Banana<T extends string> { constructor(a: boolean, property: T) }

declare function fruitFactory1<TFruit>(Fruit: new (...args: any[]) => TFruit): TFruit
declare function fruitFactory2<TFruit>(Fruit: new (a: boolean, ...args: any[]) => TFruit): TFruit

const banana1 = fruitFactory1(Banana) // Banana<string>
const banana2 = fruitFactory2(Banana) // INFERENCE FAILURE! Banana<any>

Expected behavior:
banana2 would be of type Banana<string>

Actual behavior:
banana2 is of type Banana<any>

Playground Link: Playground

Related Issues: Not that I could tell, but I don't fully grok the problem.

Notes from Gitter:

it's because we don't view Banana's T as an inference target for a call to fruitFactory -- only fruitFactory's type parameters. So we just Choose Something Good.

[the working case, banana1] is just defaulting it from the constraint for some reason. I'm not sure why without doing lots of poking through the code.

I'm pretty sure fruitFactory2 only works by 'mistake', in that we use the constraint string as the default value for T

[RyanCavanaugh]

I agree these should be the same, but disagree about which one is correct. Both fruitFactory methods say they're going to* pass an any to new Banana, and if you had said new Banana(true, null as any) we'd call that a Banana<any>.

Probably there's some arity confusion going on here with rest args; we should consider an any inference candidate to be present in both calls. This would result in zero candidates being present in fruitFactory1, falling back to the constraint type, whereas fruitFactory2 does have a candidate.

More examples:

declare class Banana<T extends string> { constructor(a: string, property: T) }

declare function fruitFactory1<TFruit>(Fruit: new (...args: any[]) => TFruit): TFruit
const banana1 = fruitFactory1(Banana) // Banana<string>

declare function fruitFactory2<TFruit>(Fruit: new (a: string, ...args: any[]) => TFruit): TFruit
const banana2 = fruitFactory2(Banana) // Banana<any>

declare function fruitFactory3<TFruit>(Fruit: new (a: string, s: "foo", ...args: any[]) => TFruit): TFruit
const banana3 = fruitFactory3(Banana) // Banana<"foo">

declare function fruitFactory4<TFruit>(Fruit: new (a: string, ...args: "foo"[]) => TFruit): TFruit
const banana4 = fruitFactory4(Banana) // Banana<"foo">

declare function fruitFactory5<TFruit>(Fruit: new (...args: "foo"[]) => TFruit): TFruit
const banana5 = fruitFactory5(Banana) // Banana<"foo">

• per our rule that unknown arity invocations are assumed to supply enough arguments

[RyanCavanaugh]

Feels like this is going to end up being a breaking change 😐

[ahejlsberg]

@RyanCavanaugh is right, we should be inferring Banana<any> in both cases. The reason we infer Banana<string> is somewhat obscure and has to do with an exception we make for mixin constructor types when instantiating an argument expression in the context of a parameter of a constructor function type. The logic we currently have in place isn't quite right and mistakenly thinks that fruitFactory1 is a mixin constructor function. It shouldn't be too hard to fix.