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

Inizia riproducendo l’esempio fornito nel TypeScript Playground collegato e confronta l’errore segnalato e il tipo risultante con il comportamento previsto. Traccia il modo in cui instantiation expressions gestiscono call and construct signatures miste, quindi aggiungi un test di regressione per l’esempio e verifica che rimanga solo la construct signature compatibile.