Update Conditional Types.md: clarify return type inference for overloaded functions

[foxcaulfield]

Description:

This pull request aims to enhance the clarity and accuracy of the TypeScript documentation regarding return type inference for overloaded functions. The current documentation states that inferences are made from the last signature, which may lead to misconceptions. Through this contribution, I have clarified that inferences are made from the last overload signature, not from the implementation signature, which is crucial for understanding how TypeScript handles type inference in such cases.

Changes Made:

• Updated the documentation in Conditional Types.md to reflect the correct behavior of return type inference for overloaded functions.
• Modified the example code to clearly distinguish between overload signatures and the implementation signature.
• Removed misleading information and provided more accurate explanation of the inference process.

This contribution aims to improve the educational value of the documentation and ensure that users have a clear understanding of how TypeScript handles type inference in the context of overloaded functions.

View Playground Example

Additional Information:

Additionally, there is an existing issue in the TypeScript repository that discusses a behavior related to return type inference for overloaded functions. It has been labelled as a "design limitation" (Link to Message).

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://victorious-plant-05c166c10-3090.centralus.5.azurestaticapps.net

[jakebailey]

Reading this again, I'm not sure that I like this change. This last one in the example is an overload, not an implementation signature; it's not uncommon for people to define these catch-all overloads at the bottom.

Perhaps it'd be better to leave the existing text as-is, and then add a new comment at the bottom that says that implementation signatures are not part of a function's type, and therefore are not considered?