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 reject incompatible signatures in situations with mixed call and construct signatures #59319

Open
Andarist opened this issue Jul 17, 2024 · 4 comments
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone

Comments

@Andarist
Copy link
Contributor

πŸ”Ž 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

@Andarist
Copy link
Contributor Author

It just occurred to me... this is very related to #51694 but currently it's not solved by #51695

@RyanCavanaugh RyanCavanaugh added Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases labels Jul 22, 2024
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Jul 22, 2024
@apendua
Copy link
Contributor

apendua commented Aug 23, 2024

@Andarist

but currently it's not solved by #51695

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
Copy link
Contributor Author

Andarist commented 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
Copy link
Contributor

apendua commented Aug 25, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Projects
None yet
Development

No branches or pull requests

3 participants