Skip to content

Type inference should consider all function parameters #50376

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
5 tasks done
jeengbe opened this issue Aug 19, 2022 · 2 comments
Closed
5 tasks done

Type inference should consider all function parameters #50376

jeengbe opened this issue Aug 19, 2022 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@jeengbe
Copy link

jeengbe commented Aug 19, 2022

Suggestion

πŸ” Search Terms

Inference, Function, Generic, Parameters

βœ… Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behaviour of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

When inferring type parameters of a function based on parameters, TypeScript should consider all parameters that use the generic type.

// @errors: 2345
interface A {
  x: string;
  y?: string;
};

declare function fn<opts extends A>(
  opts1: Partial<opts>,
  opts2: Partial<opts>
): void;


  fn({ x: "x" }, { y: "y" });
//^?
  fn<{ x: string, y: string }>({ x: "x" }, { y: "y" });
//^?

Workbench Repro

In this example, in the first function call narrows opts down to { x: string } based on the first parameter opts1 only. However, as opts is used for both opts1 and opts2, TypeScript should consider both parameters when narrowing a type for opts.
As seen in the second call, a solution does exist in which the constraint is met and neither parameter errors.

In the meantime, this can either be completely avoided by a different solution, or the generic type can be passed explicitly.

@MartinJohns
Copy link
Contributor

See #32596 (comment)

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Aug 19, 2022
@typescript-bot
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants