Use more associated types in core::iter. #23025
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
| @@ -1400,11 +1396,11 @@ pub struct Chain<A, B> { | |||
| } | |||
|
|
|||
| #[stable(feature = "rust1", since = "1.0.0")] | |||
| impl<T, A, B> Iterator for Chain<A, B> where A: Iterator<Item=T>, B: Iterator<Item=T> { | |||
| type Item = T; | |||
| impl<A: Iterator, B> Iterator for Chain<A, B> where B: Iterator<Item = A::Item> { | |||
There was a problem hiding this comment.
One bound inside <> and other inside where? Any reason why you did this?
There was a problem hiding this comment.
Moving one inside <>~ allows one to useA::Item`, but keeping as much as possible outside minimises the clutter.
|
|
||
| fn next(&mut self) -> Option<T> { | ||
| fn next(&mut self) -> Option<<I::Item as Deref>::Target> { |
There was a problem hiding this comment.
I've taken to using <Self as Iterator>::Item here when the actual expression for Item is complicated. More DRY.
|
r=me with stylistic nits addressed. (the first one I'll leave up to you) |
|
The fact that type inference failed is probably a bug but this seems fine in any case. |
| impl<I> Iterator for Cloned<I> where | ||
| I: Iterator, | ||
| I::Item: Deref, | ||
| <I::Item as Deref>::Target: Clone |
There was a problem hiding this comment.
I believe that resolution was fixed recently such that I::Item::Target: Clone should work. But perhaps the fix is not in a snapshot yet?
There was a problem hiding this comment.
Unfortunately it doesn't seem to work: although, things did change recently, so that I::Item works even if the I: Iterator bound is in a where clause (which @nagisa thankfully pointed out on an earlier version of this PR, avoiding some unnecessary inconsistency).
This concretely improves type inference of some cases (see included test). I assume the compiler struggles to reason about multiple layers of generic type parameters (even with associated-type equalities) but *can* understand pure associated types, since they are always directly computable from the input types.
|
@bors r=Gankro 7bcf rollup |
|
@nikomatsakis filed #23065. |
This concretely improves type inference of some cases (see included test). I assume the compiler struggles to reason about multiple layers of generic type parameters (even with associated-type equalities) but *can* understand pure associated types, since they are always directly computable from the input types. Thanks to @shepmaster for noticing the issue with `Cloned` (I took that example as a test case).
This concretely improves type inference of some cases (see included test). I assume the compiler struggles to reason about multiple layers of generic type parameters (even with associated-type equalities) but *can* understand pure associated types, since they are always directly computable from the input types. Thanks to @shepmaster for noticing the issue with `Cloned` (I took that example as a test case).
This concretely improves type inference of some cases (see included
test). I assume the compiler struggles to reason about multiple layers
of generic type parameters (even with associated-type equalities) but
can understand pure associated types, since they are always directly
computable from the input types.
Thanks to @shepmaster for noticing the issue with
Cloned(I took that example as a test case).