-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Generic function type argument inference problem #230
Comments
After #556 is done, this becomes more annoying. |
This doesn't seem so easy to fix. We need to either make use of information learned from type checking the first argument to infer a type variable in the second argument (but what if the arguments were in the other order?) or be able to return a polymorphic type when type checking the second argument. I think the latter is easier and it's related to some other changes I want to make anyways (e.g. #1551), but it will require some reorganization. |
Based on Reid's comment I'm moving this to 0.5.0 (or maybe even later?). |
Is there some syntax to pass type arguments explicitly when Python cannot infer the types? I am looking for something like this: |
@earshinov I think the best recent issue to discuss allowing explicit type application for functions is #6073. |
Fixes #230 Fixes #6463 I bet it fixes some other duplicates, I closed couple yesterday, but likely there are more. This may look a bit ad-hoc, but after some thinking this now starts to make sense to me for two reasons: * Unless I am missing something, this should be completely safe. Special-casing only applies to inferred types (i.e. empty collection literals etc). * Empty collections _are_ actually special. Even if we solve some classes of issues with more principled solutions (e.g. I want to re-work type inference against unions in near future), there will always be some corner cases involving empty collections. Similar issues keep coming, so I think it is a good idea to add this special-casing (especially taking into account how simple it is, and that it closer some "popular" issues).
The type checker can't infer the type argument in the call to f below, even though there seems to be no reason why it shouldn't be able to do it:
The text was updated successfully, but these errors were encountered: