-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
More flexible handling of circular types with "typeof function" inference #58616
Comments
I'm not 100% sure, but based on your description I think you're looking for #40179? |
@fatcerberus I think I'd still need to refer to the function type: |
This is sort of a bug, but really more of a possible improvement. At any rate, during type inference in the instantiation of the |
@ahejlsberg that's amazing! Honestly, I didn't expect to get this reaction seeing so many issues at this repo ❤️ |
@ahejlsberg that's perfect! Thank you! I think many people would be happy to show their appreciation to you by sponsoring but unfortunately your sponsoring page is not set up. This update changes a lot in my code and solves a problem that I was having for very long time. Sorry for delayed reply, I didn't know how TS versioning works and just installed the PR version ❤️ |
@ahejlsberg I'm doing some tests but still getting similar problems. Could you also check the following and more complex example: function withSchmuck<T, R>(arg: T, handler: (arg2: T) => R) {
console.log(arg);
return handler;
}
const foo = withSchmuck('hello', (arg) => {
return bar(arg);
});
function bar(arg: Parameters<typeof foo>[0]) {
console.log(arg);
} The |
🔍 Search Terms
"is referenced directly or indirectly in its own type annotation.ts(2502)"
"self-referencing types"
"circular types"
...
✅ Viability Checklist
⭐ Suggestion
I would like to be able to infer type of a function A that calls another function B, returning its value, relying on parameters of function A (not sure if the description is good, see the code snippet).
📃 Motivating Example
The code above, obviously, would be unable to infer return type. But hypothetically it's possible to extract its parameters.
💻 Use Cases
More flexible type inference. Currently there is no workaround for this problem. My personal use-case is to produce less types while I define service and controller for my back-end. I've simplified the code to remove unnecessary types.
At this case body is clearly
{ reportName: string }
but because of the restriction I'm not able to use it. At this example I can move body to a type variable but in practice it's more complicated because of other inferences and I would need to define body type for each controller method outside of the classes.The text was updated successfully, but these errors were encountered: