Because it's now assumed that `<T as AsExpression<SomeType>>::Output` is `T`, and there are other bounds required. So now we have 4 errors about traits not being implemented when there should be one, and none of them mention `SomeType` which is the only relevant piece of info.
-
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
Twitter is also a bit too brief to discuss this. That example is flawed because the `rustc_on_unimplemented` attr of `Iterator` probably actually belongs on `IntoIterator`, and is in its current place to work around this general issue. Hopefully I will have the RFC by Friday
-
-
Will be eager to see it! I feel that the solution is better fitting cases like iterating over a &str, where .iter() doesn't exist, but .chars() does: https://github.com/rust-lang/rust/issues/46216 … I also think that very few of these suggestions should be completely unbounded.
-
I'm using "a Python programmer who assumes you can iterate over tuples" for my example, but yeah same basic issue
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.