about summary refs log tree commit diff
path: root/src/libcore/iter
AgeCommit message (Collapse)AuthorLines
2019-10-01replace try_for_each with try_fold to generate less codeAndreas Jonson-13/+14
removes two functions to inline by combining the check functions and extra call to try_for_each
2019-09-24Rollup merge of #64296 - KodrAus:chore/iter_order_by, r=CentrilMazdak Farrokhzad-3/+3
Document the unstable iter_order_by library feature Tracking issue: #64295 Follow-up for: #62205 References the tracking issue and adds a page to the unstable book for the new unstable `iter_order_by` feature.
2019-09-21Auto merge of #64047 - timvermeulen:cmp_min_max_by, r=cuviperbors-31/+17
Add `cmp::{min_by, min_by_key, max_by, max_by_key}` This adds the following functions to `core::cmp`: - `min_by` - `min_by_key` - `max_by` - `max_by_key` `min_by` and `max_by` are somewhat trivial to implement, but not entirely because `min_by` returns the first value in case the two are equal (and `max_by` the second). `min` and `max` can be implemented in terms of `min_by` and `max_by`, but not as easily the other way around. To give an example of why I think these functions could be useful: the `Iterator::{min_by, min_by_key, max_by, max_by_key}` methods all currently hard-code the behavior mentioned above which is an ever so small duplication of logic. If we delegate them to `cmp::{min_by, max_by}` methods instead, we get the correct behavior for free. (edit: this is now included in the PR) I added `min_by_key` / `max_by_key` for consistency's sake but I wouldn't mind removing them. I don't have a particular use case in mind for them, and `min_by` / `max_by` seem to be more useful. Tracking issue: #64460
2019-09-14Simplify Iterator::{min_by, max_by} using cmp::{min_by, max_by}Tim Vermeulen-31/+17
2019-09-09Rollup merge of #64121 - timvermeulen:iter_step_by_internal, r=scottmcmMazdak Farrokhzad-1/+43
Override `StepBy::{try_fold, try_rfold}` Previous PR: https://github.com/rust-lang/rust/pull/51435 The previous PR was closed in favor of https://github.com/rust-lang/rust/pull/51601, which was later reverted. I don't think these implementations will make it harder to specialize `StepBy<Range<_>>` later, so we should be able to land this without any consequences. This should fix https://github.com/rust-lang/rust/issues/57517 – in my benchmarks `iter` and `iter.step_by(1)` now perform equally well, provided internal iteration is used.
2019-09-09document the unstable iter_order_by library featureAshley Mannix-3/+3
2019-09-06Add Iterator comparison methods that take a comparison functionTim Vermeulen-6/+103
2019-09-06Rollup merge of #64174 - GuillaumeGomez:missing-iterator-examples, r=sfacklerMazdak Farrokhzad-0/+80
Add missing code examples on Iterator trait Fixes #63865 cc @rust-lang/docs
2019-09-05Add missing code examples on Iterator traitGuillaume Gomez-0/+80
2019-09-04Override `StepBy::{try_fold, try_rfold}`Tim Vermeulen-1/+43
2019-08-30Rev::rposition counts from the wrong endXiang Fan-7/+0
Because of a compiler bug that adding `Self: ExactSizeIterator` makes the compiler forget `Self::Item` is `<I as Iterator>::Item`, we remove this specialization for now.
2019-08-22Apply clippy::needless_return suggestionsMateusz Mikuła-2/+2
2019-08-18Fix bug in iter::Chain::size_hintTim Vermeulen-8/+14
2019-08-17Rollup merge of #62737 - timvermeulen:cycle_try_fold, r=scottmcmMazdak Farrokhzad-0/+30
Override Cycle::try_fold It's not very pretty, but I believe this is the simplest way to correctly implement `Cycle::try_fold`. The following may seem correct: ```rust loop { acc = self.iter.try_fold(acc, &mut f)?; self.iter = self.orig.clone(); } ``` ...but this loops infinitely in case `self.orig` is empty, as opposed to returning `acc`. So we first have to fully iterate `self.orig` to check whether it is empty or not, and before _that_, we have to iterate the remaining elements of `self.iter`. This should always call `self.orig.clone()` the same amount of times as repeated `next()` calls would. r? @scottmcm
2019-08-16Rollup merge of #60492 - acrrd:issues/54054_chain, r=SimonSapinMazdak Farrokhzad-0/+23
Add custom nth_back for Chain Implementation of nth_back for Chain. Part of #54054
2019-08-16Rollup merge of #63615 - jens1o:patch-1, r=jonas-schievinkMazdak Farrokhzad-1/+1
Fix typo in DoubleEndedIterator::nth_back doc
2019-08-16Rollup merge of #63584 - Centril:cleanup-core-with-more-atb, r=alexregMazdak Farrokhzad-6/+2
libcore: more cleanups using `#![feature(associated_type_bounds)]` Turns out this was indeed a bootstrapping issue from a test with `./x.py check` locally after https://github.com/rust-lang/rust/pull/63534 merged. Closes https://github.com/rust-lang/rust/issues/63393 r? @alexreg cc @iluuu1994 cc https://github.com/rust-lang/rust/issues/52662
2019-08-15Fix typo in DoubleEndedIterator::nth_back docJens Hausdorf-1/+1
2019-08-15libcore: more cleanups using associated_type_boundsMazdak Farrokhzad-6/+2
2019-08-12Reduce genericity in InspectJosh Stone-12/+22
2019-08-12Reduce genericity in ScanJosh Stone-8/+17
2019-08-12Reduce genericity in TakeJosh Stone-7/+14
2019-08-12Reduce genericity in SkipJosh Stone-8/+18
2019-08-12Reduce genericity in TakeWhileJosh Stone-16/+23
2019-08-12Reduce genericity in SkipWhileJosh Stone-8/+15
2019-08-12Avoid closures in PeekableJosh Stone-1/+4
2019-08-12Reduce genericity in EnumerateJosh Stone-54/+77
2019-08-12Reduce genericity in Filter and FilterMapJosh Stone-58/+70
2019-08-12Remove genericity in StepBy::size_hintJosh Stone-5/+15
2019-08-12Reduce genericity in Copied and ClonedJosh Stone-16/+34
2019-08-12Avoid closures in the default <Zip as ZipImpl>::nextJosh Stone-5/+3
2019-08-12Reduce genericity in FlattenCompatJosh Stone-26/+52
2019-08-12Avoid closures in OnceWith and SuccessorsJosh Stone-5/+5
2019-08-12Reduce genericity in Iterator::lastJosh Stone-1/+6
2019-08-12Reduce the genericity of Map foldsJosh Stone-12/+22
2019-08-12Explicitly test Iterator::position overflowsJosh Stone-3/+2
2019-08-12Explicitly test Iterator::count overflowsJosh Stone-4/+3
2019-08-12Use if-let in is_sorted_byJosh Stone-3/+2
2019-08-12Reduce the genericity of closures in the iterator traitsJosh Stone-80/+194
By default, closures inherit the generic parameters of their scope, including `Self`. However, in most cases, the closures used to implement iterators don't need to be generic on the iterator type, only its `Item` type. We can reduce this genericity by redirecting such closures through local functions. This does make the closures more cumbersome to write, but it will hopefully reduce duplication in their monomorphizations, as well as their related type lengths.
2019-08-09Don't use associated type bounds in docs until it is stableIlija Tovilo-3/+2
2019-08-09Add missing #![feature(associated_type_bounds)]Ilija Tovilo-0/+2
2019-08-08Use associated_type_bounds where applicable - closes #61738Ilija Tovilo-26/+39
2019-08-06Rollup merge of #62459 - timvermeulen:result_sum_internal_iteration, r=scottmcmMazdak Farrokhzad-115/+43
Use internal iteration in the Sum and Product impls of Result and Option This PR adds internal iteration to the `ResultShunt` iterator type underlying the `Sum` and `Product` impls of `Result`. I had to change `ResultShunt` to hold a mutable reference to an error instead, similar to `itertools::ProcessResults`, in order to be able to pass the `ResultShunt` itself by value (which is necessary for internal iteration). `ResultShunt::process` can unfortunately no longer be an associated function because that would make it generic over the lifetime of the error reference, which wouldn't work, so I turned it into the free function `process_results`. I removed the `OptionShunt` type and forwarded the `Sum` and `Product` impls of `Option` to their respective impls of `Result` instead, to avoid having to repeat the internal iteration logic.
2019-08-06Rollup merge of #61457 - timvermeulen:double_ended_iters, r=scottmcmMazdak Farrokhzad-0/+117
Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take} Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it. I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early. I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation. The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
2019-07-29Use internal iteration in the Sum and Product impls of Result and OptionTim Vermeulen-115/+43
2019-07-27Refactoring use commun code between option, result and accumStargateur-136/+137
2019-07-17Override Cycle::try_foldTim Vermeulen-0/+30
2019-07-10Rollup merge of #62481 - czipperz:iterator-last-nth-use-for_each, r=scottmcmMazdak Farrokhzad-3/+1
Use `fold` in `Iterator::last` default implementation We already use it in all the other methods. Consistency + potential perf is a pretty nice win!
2019-07-09Use fold in Iterator::lastChris Gregory-3/+1
Replace last impl with fold
2019-07-09Tracking issue 62544 for iter_is_partitionedJosh Stone-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 17:38:12 +0000