Skip to content
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

Restrict usages of type variables in non-generalized contexts #7454

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

ayazhafiz
Copy link
Member

Type variables can only be used on functions (and in number literals as
a carve-out for now). In all other cases, a type variable takes on a
single, concrete type based on later usages. This check emits errors
when this is violated.

The implementation is to check the rank of a variable after it could be
generalized. If the variable is not generalized but annotated as a type
variable, emit an error.

Needs #7450

These are inferred vars, not rigids.
Remove branches on determining how let-bindings are introduced to the
scope. This is maybe a little more inefficient, but I think it is a huge
simplification.

One additional change this required was changing how fx suffixes are
checked. The current implementation would add additional constraints for
patterns in let bindings conditionally. However, this is unnecessary. I
believe it is sufficient to check the fx suffix by running the checks on
all introduced symbols after the type is well known (i.e. the body is
checked).
This is actually correct - the rigid approach is not. Lambda set
variables should be inferred in-scope.
I don't think this assert is actually accurate.
Type variables can only be used on functions (and in number literals as
a carve-out for now). In all other cases, a type variable takes on a
single, concrete type based on later usages. This check emits errors
when this is violated.

The implementation is to check the rank of a variable after it could be
generalized. If the variable is not generalized but annotated as a type
variable, emit an error.
@ayazhafiz ayazhafiz force-pushed the ayaz/bugfix-ts branch 2 times, most recently from 8bddbe6 to be99b82 Compare January 6, 2025 04:54
Base automatically changed from ayaz/bugfix-ts to main January 8, 2025 05:28
@lukewilliamboswell
Copy link
Collaborator

@ayazhafiz

#7450 - has merged now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants