-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Compiler is unable to resolve return type of function even though it is returning function with known return type #26623
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 a circular operation, because we have to check what the type of |
Thanks for your reply. So it sounds like you are saying, the compiler is undergoing the following "thought" process:
Meanwhile, the human being (me) is undergoing a different thought process:
This suggests that the order that type checks are performed has a significant effect on whether dependencies resolve or are deemed circular. On the surface, this seems like it shouldn't be hard to fix, but I gather it's a difficult problem or it would already be solved. This does bring up a question... The workaround I provided is obviously very simple to implement, so I'm OK using that, but is there a better, more "best practices" way to accomplish this type of thing that avoids this issue altogether? |
Yep 😉. The real issue here is that the two main operations the checker does - inference and error detection - occur at the "same time". You could imagine a different world where all inference happens, then all error checking happens, which would avoid this problem because the check of whether the argument type is assignable to the parameter type would only be part of the error-checking phase. But this would likely be at least twice as slow as the current implementation. There's no set practice that will avoid all circularity issues. The return type annotation is the best alternative for this example, I would say. |
update typescript to v4.3.5 add type annotations to methods that have an implicit any type in TS 4.3 - for more information, see microsoft/TypeScript#26623 map TS 4.3+ `JSDocTagInfo` to `CompilerJsDocTagInfo` - for more information, see microsoft/TypeScript#43312 add type guard for `TestingSystem`. in TS 4.3, `Object.defineProperties` is now generic, and returns the same type `T` as it's first argument. adding a typeguard allows consumers of this method to ensure they're receiving a `TestingSystem` object enable `noImplicitOverride` compiler flag
TypeScript Version: 3.0.1
Search Terms:
Code
Expected behavior:
Compiles without error
Actual behavior:
The following error occurs:
Comment: This error appears to be incorrect (or at least worded ambiguously) because
isNameSameAsNickname
is not referenced directly or indirectly in one of its return expressions. Specifically,isNameSameAsNickname
does not appear directly in the return expressioncompareNames(this)
nor does it appear indirectly inidentifiable.name === identifiable.nickname
.Workaround:
Declare the return type explicitly:
Playground Link:
This error is indicated in the playground with a red squiggle below
isNameSameAsNickname()
.Note: Error only occurs if
noImplicitAny
option is checkedRelated Issues:
as
operator does not work on recursive functions #5403The text was updated successfully, but these errors were encountered: