-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Change function/closure coercions to polymorphism #18599
Comments
We could probably live without doing this, but it would mean that unboxed closures have an extra virtual call indirection. |
Various incompatibilities I can think of off the top of my head that would be introduced:
The case of
This case would be harder without special-casing how inference works as well. |
Assigning P-backcompat-lang since it believed that there are some incompatibilities associated with this. But it is also not believed to be the end of the world if we do not get around to it, because there are some ideas floating around about how to address the biggest issues in a backwards-compatible fashion. (See @nikomatsakis for more details there.) Thus, P-backcompat-lang, but not 1.0. |
This is addressed by PR #19891 (which hasn't landed yet) |
Closed by #19891 |
See RFC 401.
In particular: the Function type polymorphism section.
Part of #18469
The text was updated successfully, but these errors were encountered: