Skip to content

Low priority inference trumps a much better inference that can be made from a generic signature #56931

@Andarist

Description

@Andarist

🔎 Search Terms

inference generic signature type parameters low priority

🕗 Version & Regression Information

  • This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.4.0-dev.20240102#code/CYUwxgNghgTiAEAzArgOzAFwJYHtX1ES1RAGEcBbABzxFQwB4AFGHKgZ3hAA8M7hOAJXA4YwBuwwxiAcwA08KKgCeAPlUAKAFDx47EBmRUAXPA1VWHUyzbsAlPAC8q+ADccWYHJ3w22POwA-KYA3j66FrbBZgDWIMo4iPA2HHYA2gC6ANw+AL7edqbmluzWJQ7O8GgxqDgA7qg5WmABGPBw7ACMTgQgRCTk1LT02roMACpcvPycktKoMpoA+pFW8CHwFOwyppO5FS5hurpwhjD4GgfruTm6uVp2TR2dWgD0r-AAeoFaza3tIHYACYeoRiGRKDQSCMfBMpnxUAI9FJZMtVqV1pttrt4PsnIdwgCzhcriEbnlvLojsd0aY0gAiLYyekZSm4gpPQFAt4fb5aIA

💻 Code

declare function defineComponent<Props extends Record<string, any>>(
  setup: (props: Props) => void,
  options?: {
    props?: (keyof Props)[];
  },
): (props: Props) => unknown;

const res1 = defineComponent(
  <T extends string>(_props: { msg: T }) => {
    return () => {};
  }
);

res1
// ^? const res1: <T extends string>(props: { msg: T; }) => unknown

const res2 = defineComponent(
  <T extends string>(_props: { msg: T }) => {
    return () => {};
  },
  {
    props: ["msg"],
  },
);

res2
// ^? const res2: (props: { msg: any; }) => unknown

🙁 Actual behavior

A low-priority inference made from keyof Props prevents inference from the generic signature

🙂 Expected behavior

I'd expect both of those to infer the same result: <T extends string>(props: { msg: T; }) => unknown

Additional information about the issue

There is an existential question to be asked here... what is a low-priority inference in the first place? :P Where is the line? Should every inference priority other than InferencePriority.None be treated as low-priority here?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Domain: check: Type InferenceRelated to type inference performed during signature resolution or `infer` type resolutionPossible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some cases

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions