Limit unification of types and function argument types #459
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.
Summary
In short, if we have a variable used within a function, say:
We can use type inference to get the type of x even if we don't assign it a type above.
However, if we already know the type of x, then at most the check stage should check that it is a valid argument to the function.
If we instead match it directly, we can get weird situations if the function signature specifies the argument is a union.
Then the unification stage will also state that
x
is this union, which can lead to erroneous output:Example
Will give the following:
While we expect:
Code quality
Move propagate logic to Constraint, moving logic away from
Name
which shouldn't be there.Added Tests
WIP: Argument types still leak out unnecessarily in tests: