Fix doc error for ExactSizeIterator
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.
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.
The `Iterator.nth()` documentation says "Note that all preceding elements will be consumed". I assumed from that that the preceding elements would be the *only* ones that were consumed, but in fact the returned element is consumed as well.
The way I read the documentation, I assumed that `nth(0)` would not discard anything (as there are 0 preceding elements), so I added a sentence clarifying that it does. I also rephrased it to avoid the stunted "i.e." phrasing.
branchless .filter(_).count()
I found that the branchless version is only slower if we have little to no branch misses, which usually isn't the case. I notice speedups between -5% (perfect prediction) and 60% (real world data).
This commit updates the version number to 1.17.0 as we're not on that version of
the nightly compiler, and at the same time this updates src/stage0.txt to
bootstrap from freshly minted beta compiler and beta Cargo.
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.
Forward more ExactSizeIterator methods and `is_empty` edits
- Forward ExactSizeIterator methods in more places, like `&mut I` and `Box<I>` iterator impls.
- Improve `VecDeque::is_empty` itself (see commit 4)
- All the collections iterators now have `len` or `is_empty` forwarded if doing so is a benefit. In the remaining cases, they already use a simple size hint (using something like a stored `usize` value), which is sufficient for the default implementation of len and is_empty.
Remove Self: Sized from Iterator::nth
It is an unnecessary restriction; nth neither needs self to be sized
nor needs to be exempted from the trait object.
It increases the utility of the nth method, because type specific
implementations are available through `&mut I` or through an iterator
trait object.
It is a backwards compatible change due to the special cases of the
`where Self: Sized` bound; it was already optional to include this bound
in `Iterator` implementations.
It is an unnecessary restriction; nth neither needs self to be sized
nor needs to be exempted from the trait object.
It increases the utility of the nth method, because type specific
implementations are available through `&mut I` or through an iterator
trait object.
It is a backwards compatible change due to the special cases of the
`where Self: Sized` bound; it was already optional to include this bound
in `Iterator` implementations.
Fix two small issues in iterator docs
- `collect()` is a regular method, not an adaptor (does not return an Iterator). I just randomly picked `filter` as a third common adaptor to mention instead.
- Fix example in `Map`'s docs so that it uses the DoubleEndedIterator implementation
Forward ExactSizeIterator::len and is_empty for important iterator adaptors
Forward ExactSizeIterator::len and is_empty for important iterator adaptors
Because some iterators will provide improved version of len and/or is_empty,
adaptors should forward to those implementations if possible.
