prototype an example-based approach to explaining the rewrites #1
Conversation
| Some users invoke methods on a `dyn Trait` value where the method name overlaps with a new prelude trait: | ||
|
|
||
| ```rust | ||
| trait Foo { |
There was a problem hiding this comment.
The use of Foo for both the trait here and the struct above is confusing. Can we use different names?
|
|
||
| ### Fully qualified calls to inherent methods | ||
|
|
||
| Many types define their own inherent methods with the name `from_iter`: |
There was a problem hiding this comment.
Can we establish that there is a method from_iter on the FromIter trait. I think we're requiring the reader to piece too much together here.
| } | ||
| ``` | ||
|
|
||
| Calls like `Foo::from_iter` cannot be confused with calls to `<Foo as FromIter>::from_iter`, because inherent methods take precedence over trait methods. |
There was a problem hiding this comment.
I think also we should connect the dots for the reader. Something like: "rewriting method calls to use fully qualified syntax ensures that the inherent method will be called".
| fn into_iter(&self); | ||
| } | ||
| fn bar(f: &dyn Foo) { | ||
| f.into_iter(); |
There was a problem hiding this comment.
Why would into_iter mean FromIter::into_iter? Does Foo implement FromIter?
| } | ||
| ``` | ||
|
|
||
| In these cases, the lint will sometimes rewrite to introduce additional dereferences or otherwise clarify the type of the method receiver. This ensures that the `dyn Trait` method is chosen, versus the methods from the prelude trait. For example, `f.into_iter()` above would become `(*f).into_iter()`. |
There was a problem hiding this comment.
Why does the dereference make the trait object method call unambiguous?
|
@rylev these are good comments but I don't know if I'll have time to follow up on them! maybe @jam1garner can land this and then we can continue on the main PR? |
No description provided.