Instantiation expressions don't reject incompatible signatures in situations with mixed call and construct signatures

🔎 Search Terms

instantiation expression signature applicable incompatible call construct class

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.6.0-dev.20240717#code/MYGwhgzhAEBiD29oG8C+BYAUFgLgTwAcBTaAFSIh2gF4UtpoAeU6IgDxyIDsATGLgK4BbAEZEATgD4AFGHEBzAFxkAlMtIBuetC5EA7kxbtOvGJXEBLLvJlylq5QnhbMqF1h5FQcksHhdKaE5KdQocFz8AqiscMC4cCzBOHhogsMYAIgzJFyA

💻 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

Start by reproducing the provided example in the linked TypeScript Playground and compare the reported error and resulting type with the expected behavior. Trace how instantiation expressions handle mixed call and construct signatures, then add a regression test for the example and verify that only the compatible construct signature remains.