While playing with workarounds for this issue, I found this problem (playground):
trait T {}
trait H {
type Inner: T;
}
fn assert_t<A: T>() {}
fn does_not_work<A: H<Inner=B>, B>() {
assert_t::<A::Inner>();
}
This fails with this:
error[E0277]: the trait bound `B: T` is not satisfied
--> src/lib.rs:10:16
|
10 | assert_t::<A::Inner>();
| ^^^^^^^^ the trait `T` is not implemented for `B`
|
note: required by a bound in `assert_t`
--> src/lib.rs:7:16
|
7 | fn assert_t<A: T>() {}
| ^ required by this bound in `assert_t`
help: consider restricting type parameter `B`
|
9 | fn does_not_work<A: H<Inner=B>, B: T>() {
| +++
It seems like the compiler sees A::Inner as B, but forgets additional constraints on A:Inner. Is this expected behavior? Removing the equality Inner=B makes the code compile.
I also tried doing the same with IntoIterator and for loops to see if something fun would happen if a type would implement IntoIterator, but the inner type would not implement Iterator, but I got basically the same error as above. The same thing is true for futures and await.
And they concluded it was probably intentional at the end of the OP, and the comment they link 80%? reads that way to me too, but the team hasn't actually chimed in on the issue directly.
Thank you for finding a previous "discussion"! I tried doing it myself, but github search is not good (this query doesn't find the issue you linked for some reason)