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.
This PR improves function application type generalization. This fixes #3303.
In #3303, we discussed several cases where type generalization should and should not be done over a function application.
Here are a couple of examples:
Source type
Here, we cannot generalize the universal type of the source because it can be used with operators requiring different type of content, for instance:
Ref return
If we generalize the returned value of this function, we end up with a reference cell to which we can assign values of any type:
Pure function return
This one is safe to generalize:
The idea
The idea here is that, if a universal type is present in the type of the returned value of the function, we should not generalize.
However, if this type is actually itself inside a function for which there is a non-optional argument containing it, then it should be safe to generalize.
The reason being that, if we generalize this type, it will be unified with any future application of the function it belongs to therefore making the type generalization safe.
Other examples:
Etc.