-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Parameter of a callback without a specified type next to it breaks code. #29799
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
Comments
This is basically the dual of #29791 - inference on functions proceeds left-to-right, so during the inference of |
@RyanCavanaugh Thank you, made it very clear for me. Except one part:
I am not sure how the return type can depend on parameter type if it's clear that the function returns Again, thank you very much, I hate mysteries and love when they become simple things, like you made them for me. |
We don't have a separate pass to say "Go dive into the function and check to see if all its return statements don't rely on its parameter type" - doing so would be expensive in light of the fact that extremely few real-world functions actually behave like that in practice.
An unannotated parameter isn't the same as |
@RyanCavanaugh Wow. That's another valuable insight of how the compiler works, thank you so much! If only there would be a way to know these algorithms of TS compiler without looking at it's source code and bothering you in issues. I think I will close this issue as I don't have other questions and the "Design Limitation" badge probably means I should close it. Thanks again! |
After spending almost two days in finding the issue, I ran across a few TypeScript issues on their GitHub page: - Loss of type inference converting to named parameters object microsoft/TypeScript#29791 - Parameter of a callback without a specified type next to it breaks code. microsoft/TypeScript#29799 - Convert to named parameters microsoft/TypeScript#30089 It became clear that TypeScript is unable to infer method return arguments if a generic type is used more than once in generic parameter object. Instead it returns {}. For example, the following would fail on line 28: type Convert<A, B> = (value: A) => B interface IParams<C, D> { value: C convert: Convert<C, D> doConvert: (value: C, convert: this['convert']) => D } function doSomething<E, F>(value: E, convert: Convert<E, F>) { return convert(value) } function build<G, H>(params: IParams<G, H>) { const {value, convert} = params return params.doConvert(value, convert) } const outerResult = build({ value: { a: { value: 1, }, b: 'string', }, convert: value => value.a, doConvert: (value, convert) => { const innerResult = doSomething(value, convert) innerResult.value console.log('innerResult:', innerResult) return innerResult }, }) console.log('outerResult:', outerResult) With the message: Property 'value' does not exist on type '{}'. If we replace parameter object IParams with regular ordered function parameters, the compilation succeeds. RyanCavanough (TS project lead) from GitHub commented: > We don't have a separate pass to say "Go dive into the function and > check to see if all its return statements don't rely on its parameter > type" - doing so would be expensive in light of the fact that extremely > few real-world functions actually behave like that in practice. Source: microsoft/TypeScript#29799 (comment) These modifications bring type safety to TestUtils.tsx, and therefore client-side tests of React components, while keeping almost the same ease of use as before.
TypeScript Version: 3.4.0-dev.20190207, 3.3.0
Search Terms:
type parameter, callback
Code
Expected behavior:
aParam
should bestring
in each of the four examplesActual behavior:
aParam
is for some reason{}
instead ofstring
in the second examplePlayground Link: link
I would be very grateful if someone can give me some quick directions (Is it a bug? What am I missing?). My work depends on it in a great degree.
P.S. Asked on stackoverflow and got no answer.
The text was updated successfully, but these errors were encountered: