-
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
Account for coercions in trait resolution? #62530
Comments
Related to #39801? (Similar situations it seems, like trait resolution should attempt deref coercion before erroring) |
@abonander @SimonSapin I guess this is the expected behaviour? Check RFC401
It's more like a diagnostic issue to me. |
This came up in #62528, see “Joining strings with
char
”.Reduced test case:
Output: (Identical in rustc 1.36.0 (a53f9df 2019-07-03) and rustc 1.38.0-nightly (78ca1bd 2019-07-08).)
In the
takes_str(&string)
call, the type of the_x
parameter is known to be&str
.&String
can be coerced through auto-deref.In the
takes_type_parameter(&string)
call, I imagine that trait resolution finds two solution (the_x
parameter is either&str
orchar
) but neither of them match with&string
directly, so trait resolution emits an error. Presumably, coercion are only attempted in a later phase of compilation.Is there a language design reason it has to be this way, or could we make programs like the above valid? (It then “only” be a matter of compiler implementation.)
The text was updated successfully, but these errors were encountered: