-
Notifications
You must be signed in to change notification settings - Fork 13.3k
"implement this trait" suggestions should only list traits for which that is actually legal #21420
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
Labels
Comments
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for |
huonw
added a commit
to huonw/rust
that referenced
this issue
Jan 27, 2015
That is, when offering suggestions for unresolved method calls, avoid suggesting traits for which implementing the trait for the receiver type either makes little sense (e.g. type errors, or sugared unboxed closures), or violates coherence. The latter is approximated by ensuring that at least one of `{receiver type, trait}` is local. This isn't precisely correct due to multidispatch, but the error messages one encounters in such situation are useless more often than not; it is better to be conservative and miss some cases, than have overly many false positives (e.g. writing `some_slice.map(|x| ...)` uselessly suggested that one should implement `IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`). Closes rust-lang#21420.
huonw
added a commit
to huonw/rust
that referenced
this issue
Feb 3, 2015
That is, when offering suggestions for unresolved method calls, avoid suggesting traits for which implementing the trait for the receiver type either makes little sense (e.g. type errors, or sugared unboxed closures), or violates coherence. The latter is approximated by ensuring that at least one of `{receiver type, trait}` is local. This isn't precisely correct due to multidispatch, but the error messages one encounters in such situation are useless more often than not; it is better to be conservative and miss some cases, than have overly many false positives (e.g. writing `some_slice.map(|x| ...)` uselessly suggested that one should implement `IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`). Closes rust-lang#21420.
bors
added a commit
that referenced
this issue
Feb 3, 2015
That is, when offering suggestions for unresolved method calls, avoid suggesting traits for which implementing the trait for the receiver type either makes little sense (e.g. type errors, or sugared unboxed closures), or violates coherence. The latter is approximated by ensuring that at least one of `{receiver type, trait}` is local. This isn't precisely correct due to multidispatch, but the error messages one encounters in such situation are useless more often than not; it is better to be conservative and miss some cases, than have overly many false positives (e.g. writing `some_slice.map(|x| ...)` uselessly suggested that one should implement `IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`). Closes #21420.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
E.g.
(The repetition is #21405.)
However, all of these are useless: because one cannot implement them for
usize
anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external.cc @nikomatsakis
The text was updated successfully, but these errors were encountered: