summary refs log tree commit diff
path: root/src/libcore/iter
AgeCommit message (Collapse)AuthorLines
2017-07-16Auto merge of #43237 - ↵bors-1/+1
zackmdavis:missing_sum_and_product_for_128_bit_integers, r=nagisa add u128/i128 to sum/product implementors Resolves #43235.
2017-07-14add u128/i128 to sum/product implementorsZack M. Davis-1/+1
Resolves #43235.
2017-07-13Forward more Iterator methods for iter::RevSimon Sapin-0/+8
`position` could not be implemented because calling `rposition` on the inner iterator would require more trait bounds.
2017-07-08Implement O(1)-time Iterator::nth for Range*Simon Sapin-5/+84
2017-07-08Factorize some macros in iter/range.rsSimon Sapin-57/+28
2017-07-08Remove Step::steps_between, rename steps_between_by_one to steps_betweenSimon Sapin-51/+10
2017-07-08Remove unused Step methodsSimon Sapin-34/+0
2017-07-08Remove unused Add bounds in iterator for ranges impls.Simon Sapin-23/+8
2017-07-01Delete deprecated & unstable range-specific `step_by`Scott McMurray-219/+0
Replacement: 41439 Deprecation: 42310 for 1.19 Fixes 41477
2017-06-30Track `iterator_for_each` in #42986Josh Stone-1/+1
2017-06-30Auto merge of #42782 - cuviper:iterator_for_each, r=alexcrichtonbors-0/+47
Add `Iterator::for_each` This works like a `for` loop in functional style, applying a closure to every item in the `Iterator`. It doesn't allow `break`/`continue` like a `for` loop, nor any other control flow outside the closure, but it may be a more legible style for tying up the end of a long iterator chain. This was tried before in #14911, but nobody made the case for using it with longer iterators. There was also `Iterator::advance` at that time which was more capable than `for_each`, but that no longer exists. The `itertools` crate has `Itertools::foreach` with the same behavior, but thankfully the names won't collide. The `rayon` crate also has a `ParallelIterator::for_each` where simple `for` loops aren't possible. > I really wish we had `for_each` on seq iterators. Having to use a > dummy operation is annoying. - [@nikomatsakis][1] [1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
2017-06-27Use a little more compelling example of `for_each`Josh Stone-6/+7
2017-06-23Removed as many "```ignore" as possible.kennytm-1/+1
Replaced by adding extra imports, adding hidden code (`# ...`), modifying examples to be runnable (sorry Homura), specifying non-Rust code, and converting to should_panic, no_run, or compile_fail. Remaining "```ignore"s received an explanation why they are being ignored.
2017-06-22Auto merge of #42634 - Zoxc:for-desugar2, r=nikomatsakisbors-2/+4
Change the for-loop desugar so the `break` does not affect type inference. Fixes #42618 Rewrite the `for` loop desugaring to avoid contaminating the inference results. Under the older desugaring, `for x in vec![] { .. }` would erroneously type-check, even though the type of `vec![]` is unconstrained. (written by @nikomatsakis)
2017-06-21Use `fold` to implement `Iterator::for_each`Josh Stone-4/+4
The benefit of using internal iteration is shown in new benchmarks: test iter::bench_for_each_chain_fold ... bench: 635,110 ns/iter (+/- 5,135) test iter::bench_for_each_chain_loop ... bench: 2,249,983 ns/iter (+/- 42,001) test iter::bench_for_each_chain_ref_fold ... bench: 2,248,061 ns/iter (+/- 51,940)
2017-06-20Add `Iterator::for_each`Josh Stone-0/+46
This works like a `for` loop in functional style, applying a closure to every item in the `Iterator`. It doesn't allow `break`/`continue` like a `for` loop, nor any other control flow outside the closure, but it may be a more legible style for tying up the end of a long iterator chain. This was tried before in #14911, but nobody made the case for using it with longer iterators. There was also `Iterator::advance` at that time which was more capable than `for_each`, but that no longer exists. The `itertools` crate has `Itertools::foreach` with the same behavior, but thankfully the names won't collide. The `rayon` crate also has a `ParallelIterator::for_each` where simple `for` loops aren't possible. > I really wish we had `for_each` on seq iterators. Having to use a > dummy operation is annoying. - [@nikomatsakis][1] [1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
2017-06-13Change the for-loop desugar so the `break` does not affect type inference. ↵John Kåre Alsaker-2/+4
Fixes #42618
2017-06-12Add dedicated docstrings to Sum/Product impl of ResultGeorg Brandl-1/+21
(and fix a minor grammar typo below)
2017-06-07Update docs to say iterator instead of rangeMatt Brubeck-1/+1
2017-06-04Auto merge of #42265 - Zoxc:for-sugar, r=eddybbors-3/+4
Change for-loop desugar to not borrow the iterator during the loop This is enables the use of suspend points inside for-loops in movable generators. This is illegal in the current desugaring as `iter` is borrowed across the body.
2017-06-01Change for-loop desugar to not borrow the iterator during the loopJohn Kåre Alsaker-3/+4
2017-05-31Deprecate iter::range::StepByScott McMurray-0/+15
Only exposed as DeprecatedStepBy (as of PR 41439)
2017-05-31Deprecate Range*::step_byScott McMurray-0/+6
Changed all the tests except test_range_step to use Iterator::step_by.
2017-05-31Rollup merge of #42329 - rap2hpoutre:patch-6, r=steveklabnikMark Simulacrum-2/+2
fix links to "module-level documentation" see https://github.com/rust-lang/rust/issues/42267
2017-05-31fix links to "module-level documentation"Raphaël Huchet-2/+2
2017-05-30RangeFrom should have an infinite size_hintScott McMurray-1/+7
This makes the size_hint from things like `take` more precise.
2017-05-28Auto merge of #42167 - scottmcm:iter-stepby-sizehint, r=alexcrichtonbors-1/+20
Override size_hint and propagate ExactSizeIterator for iter::StepBy Generally useful, but also a prerequisite for moving a bunch of unit tests off `Range*::step_by`. A small non-breaking subset of https://github.com/rust-lang/rust/pull/42110 (which I closed). Includes two small documentation changes @ivandardi requested on that PR. r? @alexcrichton
2017-05-26Auto merge of #42245 - frewsxcv:rollup, r=frewsxcvbors-5/+5
Rollup of 7 pull requests - Successful merges: #42169, #42215, #42216, #42224, #42230, #42236, #42241 - Failed merges:
2017-05-26Rollup merge of #42169 - scottmcm:new-step-trait-issue, r=alexcrichtonCorey Farwell-5/+5
Give step_trait a distinct tracking issue from step_by iterator_step_by has decoupled their futures, so the tracking issue should split. Old issue: https://github.com/rust-lang/rust/issues/27741 New issue: https://github.com/rust-lang/rust/issues/42168 r? @alexcrichton (another follow-up to closed PR https://github.com/rust-lang/rust/pull/42110#issuecomment-303176049)
2017-05-26Auto merge of #42014 - tbu-:pr_scan_not_fused, r=alexcrichtonbors-4/+0
Remove `FusedIterator` implementation of `iter::Scan` Fixes #41964. This is a breaking change.
2017-05-24Rollup merge of #42134 - scottmcm:rangeinclusive-struct, r=aturonMark Simulacrum-119/+55
Make RangeInclusive just a two-field struct Not being an enum improves ergonomics and consistency, especially since NonEmpty variant wasn't prevented from being empty. It can still be iterable without an extra "done" bit by making the range have !(start <= end), which is even possible without changing the Step trait. Implements merged https://github.com/rust-lang/rfcs/pull/1980; tracking issue https://github.com/rust-lang/rust/issues/28237. This is definitely a breaking change to anything consuming `RangeInclusive` directly (not as an Iterator) or constructing it without using the sugar. Is there some change that would make sense before this so compilation failures could be compatibly fixed ahead of time? r? @aturon (as FCP proposer on the RFC)
2017-05-23Give step_trait a distinct tracking issue from step_byScott McMurray-5/+5
iterator_step_by has decoupled their futures, so the tracking issue should split.
2017-05-23Update description of iter::StepByScott McMurray-1/+1
2017-05-23Override size_hint and propagate ExactSizeIterator for iter::StepByScott McMurray-0/+19
Generally useful, but also a prerequisite for moving a bunch of unit tests off Range::step_by.
2017-05-21Return a correct size_hint for degenerate inclusive rangesScott McMurray-0/+4
Fixes https://github.com/rust-lang/rust/issues/42135 Found while fixing run-pass/range_inclusive test failure.
2017-05-21Make RangeInclusive just a two-field structScott McMurray-120/+52
Not being an enum improves ergonomics, especially since NonEmpty could be Empty. It can still be iterable without an extra "done" bit by making the range have !(start <= end), which is even possible without changing the Step trait. Implements RFC 1980
2017-05-20Auto merge of #42111 - ollie27:stab, r=Mark-Simulacrumbors-1/+1
Correct some stability versions These were found by running tidy on stable versions of rust and finding features stabilised with the wrong version numbers.
2017-05-20Correct some stability versionsOliver Middleton-1/+1
These were found by running tidy on stable versions of rust and finding features stabilised with the wrong version numbers.
2017-05-19Auto merge of #41439 - ivandardi:master, r=BurntSushibors-2/+70
Stabilize step_by by adding it to Iterator (issue #27741) Inspired by itertools' `take()` method. See issue #27741
2017-05-15Update documentationIvan Dardi-2/+1
2017-05-15Remove `FusedIterator` implementation of `iter::Scan`Tobias Bucher-4/+0
Fixes #41964. This is a breaking change.
2017-05-12Fix commit derp and update implementations and documentationIvan Dardi-2/+71
2017-05-11Fix typo in size_hint example commentMartin Glagla-1/+1
2017-04-26Rollup merge of #41493 - scottmcm:fix-step-replace, r=sfacklerAriel Ben-Yehuda-6/+6
Step::replace_one should put a one, not a zero (Issue #41492) Turns out all six of the replace_* impls were backwards.
2017-04-25Clarify "side effect" in peek's docssteveklabnik-2/+3
Fixes #33269
2017-04-23Step::replace_one should put a one, not a zero (Issue #41492)Scott McMurray-6/+6
Turns out all six of these impls are incorrect.
2017-04-15code formatking6cong-5/+5
2017-04-11Clarify Iterator::position docSebastian Hahn-2/+6
Extend the example a little bit to show behaviour better.
2017-04-03iter: Simplification in rfind's provided implementationUlrik Sverdrup-1/+1
- Prefer simpler constructs instead of going through &mut I's Iterator implementation.
2017-04-03iter: Use underlying find/rfind for the same methods in RevUlrik Sverdrup-0/+12
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-07 13:14:35 +0000