Conversation
So far, we have assumed that `untyped` matches any type. This approach had a problem that when an argument is untyped, it matches a method signature, and when the argument is any concrete type, it does not match the same method signature, and if the result of the match affects the type of the argument itself, the analysis would oscillate and loop endlessly. This change makes `untyped` not match any other type. This will have a significant difference from gradutal typing's `untyped` (or `any`). Instead, we suppress diagnostics like `expected: C, actual: untyped`. We expect that this will not make much difference on the user side. By assuming that untyped does not match a concrete type, it is expected that the scope of analysis will be narrower (not enough analysis can be done after the method call that fails to resolve overload). Therefore, we decided that if there is no overload in the method signature, the method signature will always be chosen (errors will be reported if there is a discrepancy in the type or number of arguments). This is expected to allow many method calls to be parsed with concrete types afterwards, even if there are discrepancies in arguments.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
So far, we have assumed that
untypedmatches any type. This approach had a problem that when an argument is untyped, it matches a method signature, and when the argument is any concrete type, it does not match the same method signature, and if the result of the match affects the type of the argument itself, the analysis would oscillate and loop endlessly.This change makes
untypednot match any other type. This will have a significant difference from gradutal typing'suntyped(orany). Instead, we suppress diagnostics likeexpected: C, actual: untyped. We expect that this will not make much difference on the user side.By assuming that untyped does not match a concrete type, it is expected that the scope of analysis will be narrower (not enough analysis can be done after the method call that fails to resolve overload). Therefore, we decided that if there is no overload in the method signature, the method signature will always be chosen (errors will be reported if there is a discrepancy in the type or number of arguments). This is expected to allow many method calls to be parsed with concrete types afterwards, even if there are discrepancies in arguments.