inconsistent infer behaviour

[albert-mirzoyan]

TypeScript Version: 3.1.0-dev.20180831

Search Terms: infer, unused generic type

In below example infer behaves inconsistently when the generic type argument is unused.

It should either:

• infer {} for all cases due to some "unused hence ignore" logic
• "extends" should not assert it
• "expected behavior".

In real life scenario T is used to carry additional type info.

Code

type Unpack<A> = A extends Parent<infer T>? T : never;
interface Parent<T> {
    //foo:T
}
interface Child extends Parent<string>{
    bar
}
type Cousin = Parent<string> & {
    baz
}

type PP = Parent<string>;

type T1 = Unpack<Parent<number>>;   //T1 is number OK
type T2 = Unpack<Child>;            //T2 is {}     NOT-OK
type T3 = Unpack<PP>;               //T3 is string OK
type T4 = Unpack<Cousin>;           //T4 is {}     NOT-OK

Expected behavior:
T1 to infer number
T2 to infer string
T3 to infer string
T4 to infer string

Actual behavior:
T1 infers number
T2 infers {}
T3 infers string
T4 infers {}

Workaround:
Uncomment foo, use the generic type in any form

Playground Link:
Playground Link

Related Issues:

[RyanCavanaugh]

https://github.com/Microsoft/TypeScript/wiki/FAQ#why-doesnt-type-inference-work-on-this-interface-interface-foot---

[albert-mirzoyan]

@RyanCavanaugh I get the point, but the behavior is inconsistent and it leads to tricks to workaround it. For consistency shouldn't T1 and T3 also infer {}

[mattmccutchen]

The inference algorithm has a special case when comparing two parameterizations of the same generic type. Since it already checks the variances of the type parameters to know whether to make a covariant or a contravariant inference, it's easy to check for an independent type parameter and make no inference at all. Here is a proof of concept that works when strictFunctionTypes is enabled. I'm unfamiliar with the reason why variance computation is disabled when strictFunctionTypes is disabled. @RyanCavanaugh, would you be interested in having me make a complete PR?

[RyanCavanaugh]

@mattmccutchen sure

[mattmccutchen]

PR is #26847

[vrachels]

+1
I hit this issue while trying to use a generator pattern.
My super-simplified repro case:

class Foo<Type, Data>
{
    foo: Type;
    // dummy(): Data | undefined { return undefined; }
}
class Fs extends Foo<'fs', number> {}

const gen: { [k: string]: () => any } = {};

const Get = <Type extends string, Data>(f: Foo<Type, Data>): Data =>
{
    const res = gen[f.foo]();
    const ret = res as Data;
    return ret;
};

const w = Get(new Foo<'f1', number>()); // w inferred as number
const x = Get(new Fs());                // x inferred as {}, unless dummy is uncommented, then number

Looks like the same issue, but haven't tested if the PR fixes this.

A note that seems interesting is that the use of the explicit Foo<T,D> as the parameter does get properly inferred.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.