Open kpreid opened 1 year ago
A solution that might be more elegant in particular code is to destructure the argument — let FooC { field } = check;
. That's harder to suggest automatically, however, since it involves introducing a new statement and variables.
Code
Current output
Desired output
Rationale and extra context
If users are not given this advice, it will not be obvious how to proceed; they may think that it is not even possible. For me at least, it is obvious only in hindsight that
check
argument is of a different type than the outgoing return value, andThe alternate mental model I was working with before I understood the problem was something like:
Self::Check
is an alias for a particularimpl Sized
impl
or module knows (being in the defining scope of theimpl Trait
), is an alias forFooC
so
check
should be of typeFooC
already. Now that I understand what's actually going on, it makes much more sense that the compiler would work this way (scope-dependent type equality would be a nightmare), but it wasn't obvious when I started.Other cases
No response
Anything else?
This exact same problem happens with TAIT; I just think it's just a little less clear and more important for associated types in traits.
Another detail to consider is what the output should be when the underlying type does not have such a field (or method). I think there should still be a similar hint, but phrased differently — in general, this hint should show up whenever
@rustbot label +A-impl-trait +F-type_alias_impl_trait