-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Could type inference insert coercions to accommodate box desugaring? #22405
Comments
cc #22181 |
(Just for the record: I am generally not a fan of tracking the "sizedness" of type variables because it is not something we necessarily know at the time that the type variable is created and so forth. But I'd consider it if we cannot find another solution.) |
Update: this code errors with
I have no idea what's been going on with the placement syntax, so I'm not sure if this is expected or not. It seems like what @nikomatsakis is talking about. |
My first attempt at a solution resulted in #27292, but I now believe there is no point in desugaring to Rust code when we can handle this much better in type-checking if we know it's placement syntax and not just a bunch of function calls (see comment). |
Triage: as far as I know, everything about box syntax is going back to first base, right? I'm not sure if this issue is useful or not. |
The problem here was previously documented as a drawback in rust-lang/rfcs#809 (with similar details provided in Appendix B).
Demonstration code:
The question posed by this issue is: Could we enhance the type inference and/or the design of this protocol so that, by tracking the sized-ness of the type unification variables, we could determine where coercions need to be inserted.
The text was updated successfully, but these errors were encountered: