Repository navigation
Instantiation expressions don't reject incompatible signatures in situations with mixed call and construct signatures #59319
Description
🔎 Search Terms
instantiation expression signature applicable incompatible call construct class
🕗 Version & Regression Information
- This is the behavior in every version I tried
⏯ Playground Link
💻 Code
class Foo {}
type Test = {
<T extends number>(arg: T): T;
new <T extends string>(arg: T): Foo;
};
declare const test: Test;
const intantiated = test<"">;🙁 Actual behavior
An error gets reported:
Type 'string' does not satisfy the constraint 'number'.(2344)
And the final type of instantiated is computed as:
const intantiated: {
<T extends number>(arg: T): T;
new (arg: ""): Foo;
}🙂 Expected behavior
I'm not 100% sure but it feels like this type could be successfully instantiated to { new (arg: ""): Foo; }. This is the only signature that matches the given type arguments.
Additional information about the issue
No response
Activity
Andarist commentedon Jul 17, 2024
It just occurred to me... this is very related to #51694 but currently it's not solved by #51695
apendua commentedon Aug 23, 2024
Mateusz Burzyński (@Andarist)
Have you tried rebasing it onto latest
main? I tried something very similar to your PR on my end and it seems like it's also a valid fix for the issue described here.Andarist commentedon Aug 25, 2024
I can try later but this PR only limits the search within a "group" of signatures. Call and construct signatures are kept separately so it shouldn't change the behavior for this case here without some extra tweaks. IIRC I checked it when posting the comment above.
apendua commentedon Aug 25, 2024
Mateusz Burzyński (@Andarist) Yeah that makes sense. But I think the reason you're seeing the error in the first place is because the first signature has a "number" type constraint so if it gets filtered out the error goes away.