-
-
Notifications
You must be signed in to change notification settings - Fork 419
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
Arrow type in a method's type argument constraint causes a failed assertion #1809
Comments
We talked during the sync about lifting the "no arrow" restriction all together. There's one concern I see, which is it can lead to constraints with no "reduced form". class Foo[X: box->Any #any] The constraint I think this is similar to |
This better reflects their use. It allows arrow types and tuples to appear in these positions. Also properly deny arrow types from appearing in constraints, fixing ponylang#1809.
This better reflects their use. It allows arrow types and tuples to appear in these positions. It also denies capability sets from appearing in these positions. These have an extremely limited use, and are unlikely to be used by anyone. As a side effect, the default capability in these positions now corresponds to the type default, rather than #any. Also properly deny arrow types from appearing in constraints, fixing ponylang#1809.
This better reflects their use. It allows arrow types and tuples to appear in these positions. It also denies capability sets from appearing in these positions. These have an extremely limited use, and are unlikely to be used by anyone. As a side effect, the default capability in these positions now corresponds to the type default, rather than #any. Also properly deny arrow types from appearing in constraints, fixing ponylang#1809.
) This better reflects their use. It allows arrow types and tuples to appear in these positions. It also denies capability sets from appearing in these positions. These have an extremely limited use, and are unlikely to be used by anyone. As a side effect, the default capability in these positions now corresponds to the type default, rather than #any. Also properly deny arrow types from appearing in constraints, fixing #1809.
This is the same as #1694, but in a method's type parameters rather than a class. My guess is because of the
(opt->check.frame->method == NULL)
check in libponyc/pass/syntax.c#L451Removing the check makes the snippet above cause the expected error. However it breaks collections/map.pony#L241, which uses
H2: HashFunction[this->K!] val
.This kind of constraint is currently disallowed on type level generics due to the check in
syntax.c
. For example :My guess is that arrow types should be allowed in constraints, but only as a type argument, not at the top level. I don't see a reason for there to be a difference between methods and class arguments.
The text was updated successfully, but these errors were encountered: