Now that the necessary associated types exist for the `IntoIterator` trait this
commit stabilizes the trait as-is as well as all existing implementations.
Now that the necessary associated types exist for the `IntoIterator` trait this
commit stabilizes the trait as-is as well as all existing implementations.
The first commit adds a short note which I believe will reduce worries in people who work with closures very often and read the Rust book for their first time.
The second commit consists solely of tiny typo fixes. In some cases, I changed "logical" quotations like
She said, "I like programming".
to
She said, "I like programming."
because the latter seems to be the prevalent style in the book.
`IntoIterator` now has an extra associated item:
``` rust
trait IntoIterator {
type Item;
type IntoIter: Iterator<Self=Self::Item>;
}
```
This lets you bind the iterator \"`Item`\" directly when writing generic functions:
``` rust
// hypothetical change, not included in this PR
impl Extend<T> for Vec<T> {
// you can now write
fn extend<I>(&mut self, it: I) where I: IntoIterator<Item=T> { .. }
// instead of
fn extend<I: IntoIterator>(&mut self, it: I) where I::IntoIter: Iterator<Item=T> { .. }
}
```
The downside is that now you have to write an extra associated type in your `IntoIterator` implementations:
``` diff
impl<T> IntoIterator for Vec<T> {
+ type Item = T;
type IntoIter = IntoIter<T>;
fn into_iter(self) -> IntoIter<T> { .. }
}
```
Because this breaks all downstream implementations of `IntoIterator`, this is a [breaking-change]
---
r? @aturon
Fixes#22047
Range<u64> and Range<i64> may be longer than usize::MAX on 32-bit
platforms, and thus they cannot fulfill the protocol for
ExactSizeIterator. We don't want a nonobvious platform dependency in
basic iterator traits, so the trait impl is removed.
The logic of this change assumes that usize is at least 32-bit.
This is technically a breaking change; note that Range<usize> and
Range<isize> are always ExactSizeIterators.
[breaking-change]
* Remove type parameters from `IteratorExt::cloned`
* Rename `IntoIterator::Iter` to `IntoIterator::IntoIter`
* Mark `IntoIterator::into_iter` as stable (but not the trait, only the method).
When self.start > self.end, these iterators simply return None,
so we adjust the size_hint to just return zero in this case.
Certain optimizations can be implemented in and outside libstd if we
know we can trust the size_hint for all inputs to for example
Range<usize>.
This corrects the ExactSizeIterator implementations, which IMO were
unsound and incorrect previously, since they allowed a range like (2..1)
to return a size_hint of -1us in when debug assertions are turned off.
Right now it is not possible to write a `for` loop without opting-in to the
`core` feature due to the way they're expanding (calling
`::std::iter::IntoIterator::into_iter`). There are some planned tweaks to the
`IntoIterator` trait (adding an `Item` associated type) which will cause
implementations of `IntoIterator` to break, but the *usage* of the trait is
currently stable.
This commit marks the method `into_iter` as stable as the name will not be
changing, nor the fact that it takes no arguments and returns one type (which is
determiend by the `Self` type). This means that usage of `for` loops is now
stable but manual implementations of the `IntoIterator` trait will continue to
be unstable.
This is in preparation for stabilization of the `IntoIterator` trait. All
implementations and references to `Iter` need to be renamed to `IntoIter`.
[breaking-change]
When self.start > self.end, these iterators simply return None,
so we adjust the size_hint to just return zero in this case.
Certain optimizations can be implemented in and outside libstd if we
know we can trust the size_hint for all inputs to for example
Range<usize>.
This corrects the ExactSizeIterator implementations, which IMO were
unsound and incorrect previously, since they allowed a range like (2..1)
to return a size_hint of -1us in when debug assertions are turned off.
This removes the `ByRef` iterator adaptor to stay in line with the changes to
`std::io`. The `by_ref` method instead just returns `&mut Self`.
This also removes the implementation of `Iterator for &mut Iterator` and instead
generalizes it to `Iterator for &mut I` where `I: Iterator + ?Sized`. The
`Box<I>` implementations were also updated.
The extra check caused by the expect() call can, in general, not be
optimized away, because the length of the iterator is unknown at compile
time, causing a noticable slow-down. Since the check only triggers if
the element isn't actually found in the iterator, i.e. it isn't
guaranteed to trigger for ill-behaved ExactSizeIterators, it seems
reasonable to switch to an implementation that doesn't need the check
and just always returns None if the value isn't found.
Benchmark:
````rust
let v: Vec<u8> = (0..1024*65).map(|_| 0).collect();
b.iter(|| {
v.as_slice().iter().rposition(|&c| c == 1)
});
````
Before:
````
test rposition ... bench: 49939 ns/iter (+/- 23)
````
After:
````
test rposition ... bench: 33306 ns/iter (+/- 68)
````
This removes the `ByRef` iterator adaptor to stay in line with the changes to
`std::io`. The `by_ref` method instead just returns `&mut Self`.
This also removes the implementation of `Iterator for &mut Iterator` and instead
generalizes it to `Iterator for &mut I` where `I: Iterator + ?Sized`. The
`Box<I>` implementations were also updated.
This is a breaking change due to the removal of the `std::iter::ByRef` type. All
mentions of `ByRef<'a, T>` should be replaced with `&mut T` to migrate forward.
[breaking-change]
The extra check caused by the expect() call can, in general, not be
optimized away, because the length of the iterator is unknown at compile
time, causing a noticable slow-down. Since the check only triggers if
the element isn't actually found in the iterator, i.e. it isn't
guaranteed to trigger for ill-behaved ExactSizeIterators, it seems
reasonable to switch to an implementation that doesn't need the check
and just always returns None if the value isn't found.
Benchmark:
````rust
let v: Vec<u8> = (0..1024*65).map(|_| 0).collect();
b.iter(|| {
v.as_slice().iter().rposition(|&c| c == 1)
});
````
Before:
````
test rposition ... bench: 49939 ns/iter (+/- 23)
````
After:
````
test rposition ... bench: 33306 ns/iter (+/- 68)
````
Now that associated types are fully implemented the iterator adaptors only need
type parameters which are associated with actual storage. All other type
parameters can either be derived from these (e.g. they are an associated type)
or can be bare on the `impl` block itself.
This is a breaking change due to the removal of type parameters on these
iterator adaptors, but code can fairly easily migrate by just deleting the
relevant type parameters for each adaptor. Other behavior should not be
affected.
Closes#21839
[breaking-change]
Now that associated types are fully implemented the iterator adaptors only need
type parameters which are associated with actual storage. All other type
parameters can either be derived from these (e.g. they are an associated type)
or can be bare on the `impl` block itself.
This is a breaking change due to the removal of type parameters on these
iterator adaptors, but code can fairly easily migrate by just deleting the
relevant type parameters for each adaptor. Other behavior should not be
affected.
Closes#21839
[breaking-change]
The new `::ops::Range` has separated implementations for each of the
numeric types, while the old `::iter::Range` has one for type `Int`.
However, we do not take output bindings into account when selecting
traits. So it confuses `typeck` and makes the new range does not work as
good as the old one when it comes to type inference.
This patch implements `Iterator` for the new range for one type `Int`.
This limitation could be lifted, however, if we ever reconsider the
output types' role in type inference.
Closes#21595Closes#21649Closes#21672
The new `::ops::Range` has separated implementations for each of the
numeric types, while the old `::iter::Range` has one for type `Int`.
However, we do not take output bindings into account when selecting
traits. So it confuses `typeck` and makes the new range does not work as
good as the old one when it comes to type inference.
This patch implements `Iterator` for the new range for one type `Int`.
This limitation could be lifted, however, if we ever reconsider the
output types' role in type inference.
Closes#21595Closes#21649Closes#21672
