Skip to content
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

Instantiation expressions don't filter signatures with non-matching constraints #51694

Open
Andarist opened this issue Nov 30, 2022 · 5 comments Β· May be fixed by #51695
Open

Instantiation expressions don't filter signatures with non-matching constraints #51694

Andarist opened this issue Nov 30, 2022 · 5 comments Β· May be fixed by #51695
Labels
Experimentation Needed Someone needs to try this out to see what happens Suggestion An idea for TypeScript
Milestone

Comments

@Andarist
Copy link
Contributor

Bug Report

πŸ”Ž Search Terms

instantiation expression, overload

πŸ•— Version & Regression Information

  • This is the behavior in every version I tried

⏯ Playground Link

Playground link with relevant code

πŸ’» Code

declare function foo<T extends keyof HTMLElementTagNameMap>(arg: T): HTMLElementTagNameMap[T];
declare function foo<T extends HTMLElement>(arg: T): T;

type FirstFoo = typeof foo<"div">; // Type 'string' does not satisfy the constraint 'HTMLElement'.(2344)

πŸ™ Actual behavior

This instantiation expression errors despite the fact that a matching signature exists.

πŸ™‚ Expected behavior

It sounds likely that most people would assume that this should work similarly to how overloads are chosen - but instead an intersection is being created based on all signatures with the same type arguments arity.

originally reported by @herjiict here

@fatcerberus
Copy link

an intersection is being created based on all signatures with the same type arguments arity

Is it that, or is it just picking the last overload, similar to what happens with Parameters?

@Andarist
Copy link
Contributor Author

IIRC what I’ve seen when debugging this - it’s an intersection, it’s not picking a single matching signature.

I think that it makes sense per the second part of this comment: #51695 (comment) . It’s just that when mapping those signatures reportErrors was always set to true and non-matching signatures were not rejected

@Andarist
Copy link
Contributor Author

Andarist commented Dec 1, 2022

I went back to recheck the implementation, "intersection" definitely caught my eye somewhere around this code but it seems that it was in some different parts.

So this isn't actually becoming an intersection, but the effect is kinda similar - it's an object type with multiple signatures (and more):
https://github.dev/microsoft/TypeScript/blob/70d5cb28275d35e45a0f84aa981b45e6fb059160/src/compiler/checker.ts#L33667-L33679

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Experimentation Needed Someone needs to try this out to see what happens labels Dec 2, 2022
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Dec 2, 2022
@RyanCavanaugh
Copy link
Member

@ahejlsberg any thoughts?

@apendua
Copy link
Contributor

apendua commented Aug 23, 2024

What would need to happen from the TypeScript team perspective for this change to be accepted? It seems to be a very reasonable improvement and it also addresses a couple other problems (linked above).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Experimentation Needed Someone needs to try this out to see what happens Suggestion An idea for TypeScript
Projects
None yet
4 participants