Infer works differently for interface and type alias

[UnVuTWFu]

🔎 Search Terms

infer, index signature

🕗 Version & Regression Information

• This won't compile.
• This is the behavior in every version I tried,.

⏯ Playground Link

Playground link with relevant code

💻 Code

interface IntA {
    id: string;
}

type TypeA = {
    id: string
}

type Get<T> = T extends { [index: string]: infer A } ? true : false;
type Res1 = Get<IntA>
// Res1 is false
type Res2 = Get<TypeA>
// Res2 is true

🙁 Actual behavior

When using interface,I cannot get type of A(as example above).But if instead of interface,the infer works.

🙂 Expected behavior

I'd expect the same behaviour in both cases,or I can control pass type or interface.

Additional information about the issue

maybe related #15300

[mkantor]

maybe related #15300

This is a direct consequence of #15300. You're trying to infer out of an index signature, but interfaces don't have implicit index signatures as described in #15300.

If you add an explicit index signature to IntA then your code works.

[UnVuTWFu]

Thanks so rapid response.For my actual use,I want pass a generic type and extract specific types,just like this

type Generic = { [name: string]: any }
type ExtractARule<R extends Generic> = R extends { [name: string]: infer VALUE } ? VALUE extends string | number ? R : never : never
type ExtractBRule<R extends Generic> = R extends { [name: string]: infer VALUE } ? VALUE extends boolean ? R : never : never

As far as I konw,if generic type = {[index:string]:any},interface and type will have same behaviour shown in playground

For my use,type works well,but interface only return never without any error or warning.Maybe there should have a way to declare one type only need type or interface if program rely on this behaviour.

[mkantor]

Are you looking for something like this?

type ExtractARule<R> = R[keyof R] extends string | number ? R : never

[MartinJohns]

🕗 Version & Regression Information

• This won't compile.

Compiles just fine.

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Similar Issues

Here are the most similar issues I found

• (69%) microsoft/typescript#28861: Intersection type disrupts generic inference
• (68%) microsoft/typescript#19534: Union type as key works for `type` but not for `interface`
• (68%) microsoft/typescript#61699: interface&type inference
• (67%) microsoft/typescript#54213: `infer` not returning expected inner type if another inner type is used in the outer type result
• (67%) microsoft/typescript#33099: index signature is missing for type
• (66%) microsoft/typescript#18305: Generic interface inheriting from another generic interface results in incorrect inference
• (66%) microsoft/typescript#15300: Index signature is missing in type (only on interfaces, not on type alias)
• (66%) microsoft/typescript#59361: The type of inference is inaccurate
• (65%) microsoft/typescript#55146: Generic parameters info is not inferred in conditional types over ancestor
• (65%) microsoft/typescript#26688: Infer of extended generic type

If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

Possibly Working as Intended

It looks like this behavior might be intentional. Here's what a computer had to say about it.

infer is only triggered if the source type is actually assignable to the pattern on the right–hand side of extends.

For an anonymous object type (the literal type { id: string }, even when referred to through a type alias) the compiler fabricates a synthetic string-index signature whose value type is the union of all property types plus undefined. That synthetic index signature exists so you can write code like:

const o = { id: "x" };
const v = o[someString]; // string | undefined

Because that synthetic signature is present, the anonymous type is considered assignable to { [k: string]: A }, so the conditional T extends { [k: string]: infer A } succeeds and A is inferred (to string | undefined), making Get<TypeA> evaluate to true.

Named object types—interfaces and classes—never get this synthetic index signature. They are open types and can later be augmented (e.g., via declaration merging), so adding an implicit index signature to them would be unsound. Since interface IntA { id: string } has no real string-index signature, it is not assignable to { [k: string]: any }, the extends test fails, and Get<IntA> becomes false.

If you want an interface to match that pattern, declare an explicit index signature:

interface IntA {
  id: string;
  [k: string]: string; // now it matches
}

The observed difference is therefore intentional and reflects the way TypeScript models indexing for anonymous versus named object types.