| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
When reading this I wondered what “some significant optimizations” referred to. As far as I can tell, the specialization of `.fuse()` is the only case where `FusedIterator` has any impact at all. Is this accurate @Stebalien?
|
|
|
|
|
|
|
|
Add implementation of Extend for ()
This is useful in some generic code which wants to collect iterators of items into a result.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This also implements ExactSizeIterator where applicable.
Addresses most of the Iterator traits mentioned in #23708.
|
|
|
|
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
|
|
During the RFC, it was discussed that figuring out whether a range is empty was subtle, and thus there should be a clear and obvious way to do it. It can't just be ExactSizeIterator::is_empty (also unstable) because not all ranges are ExactSize -- not even Range<i32> or RangeInclusive<usize>.
|
|
|
|
This is the core method in terms of which the other methods (fold, all, any, find, position, nth, ...) can be implemented, allowing Iterator implementors to get the full goodness of internal iteration by only overriding one method (per direction).
|
|
Add iterator method .rfold(init, function); the reverse of fold
rfold is the reverse version of fold.
Fold allows iterators to implement a different (non-resumable) internal
iteration when it is more efficient than the external iteration implemented
through the next method. (Common examples are VecDeque and .chain()).
Introduce rfold() so that the same customization is available for reverse
iteration. This is achieved by both adding the method, and by having the
Rev\<I> adaptor connect Rev::rfold → I::fold and Rev::fold → I::rfold.
On the surface, rfold(..) is just .rev().fold(..), but the special case
implementations allow a data structure specific fold to be used through for
example .iter().rev(); we thus have gains even for users never calling exactly
rfold themselves.
|
|
|
|
|
|
rfold is the reverse version of fold.
Fold allows iterators to implement a different (non-resumable) internal
iteration when it is more efficient than the external iteration
implemented through the next method. (Common examples are VecDeque and
.chain()).
Introduce rfold() so that the same customization is available for
reverse iteration. This is achieved by both adding the method, and by
having the Rev<I> adaptor connect Rev::rfold -> I::fold, Rev::fold -> I::rfold.
|
|
Part of #44600.
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
doc: make into_iter example more concise
Also, remove dupe example
|
|
|
|
Resolves #43235.
|
|
(and fix a minor grammar typo below)
|
|
|
|
- Prefer simpler constructs instead of going through &mut I's Iterator
implementation.
|
|
The code example in the trait documentation of ExactSizeIterator
has an incorrect implementation of the len method that does not return
the number of times the example iterator 'Counter' will iterate. This
may confuse readers of the docs as the example code will compile but
doesn't uphold the trait's contract.
This is easily fixed by modifying the implementation of len and changing
the assert statement to actually assert the correct behaviour. I also
slightly modified a code comment to better reflect what the method
returns.
|
|
This was never established as a convention we should follow in the 'More
API Documentation Conventions' RFC:
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md
|
|
Fix a few impl stability attributes
The versions show up in rustdoc.
|
|
|
|
The versions show up in rustdoc.
|
|
Clarify Extend behaviour wrt existing keys
This seems to be consistent with all the Extend implementations I found, and isn't documented anywhere else afaik.
|
|
This introduces a private iterator adapter `ResultShunt`, which allows
treating an iterator of `Result<T, E>` as an iterator of `T`.
|
|
|
|
|
|
|
|
|
|
|
|
Add impls for `&Wrapping`. Also `Sum`, `Product` impls for both `Wrapping` and `&Wrapping`.
There are two changes here (split into two commits):
- Ops for references to `&Wrapping` (`Add`, `Sub`, `Mul` etc.) similar to the way they are implemented for primitives.
- Impls for `iter::{Sum,Product}` for `Wrapping`.
As far as I know `impl` stability attributes don't really matter so I didn't bother breaking up the macro for two different kinds of stability. Happy to change if it does matter.
|
|
|
|
|
|
|
