Miss Dada  🏳️‍⚧️

I've got an RFC I'm writing to provide an attribute which can be placed on impls to tell rustc "Please do not recommend this impl". Explicit annotation is the only fix in this case I think. My desired behavior in *this* case is "Follow the impl chain to N-1 places"

This would also help in cases where you want Rust to recommend another impl, but it doesn't because there are two "possible" cases that could apply (even though one never does)

There's a few cases like that in Diesel right now, and they're the difference between "<3 page long type>: ExecuteDsl is not satisfied" and "String: FromSql<Integer> is not satisfied"

It does sound like an annotation with "similar" behavior to `rustc_on_unimplemented` would be enough for your case, but it'd be nice if rustc had better behavior for this case by default (I want to minimize how many hints library writers need to add for us to do the right thing).

Heh. The "motivation" section of this RFC specifically talks about how the current behavior causes the "rustc_on_unimplemented" attribute to be shown in places that it shouldn't, where it is specifically harmful

There's some work around matching in that attribute to avoid that problem: https://github.com/rust-lang/rust/issues/44755 …

(Unless I'm misunderstanding the problem)

That seems like the wrong approach. There's never a case where "`T: Iterator` is not satisfied" is more useful than "Try calling `.iter()` or a similar method". Stating "don't change your error due to this impl" so that we see "`T: IntoIterator` is not satisfied" is more helpful