about summary refs log tree commit diff
path: root/src/libcore/iter.rs
AgeCommit message (Collapse)AuthorLines
2015-02-23Add documentation to associated types in libcore, libstdIvan Petkov-0/+3
2015-02-20Add examples for iter::range_stepSteve Klabnik-2/+47
2015-02-18rollup merge of #22286: nikomatsakis/variance-4bAlex Crichton-5/+6
Conflicts: src/librustc/middle/infer/combine.rs src/librustc_typeck/check/wf.rs
2015-02-18Round 1 fixes and rebase conflictsAlex Crichton-5/+5
2015-02-18rollup merge of #22491: Gankro/into_iterAlex Crichton-3/+3
Conflicts: src/libcollections/bit.rs src/libcollections/linked_list.rs src/libcollections/vec_deque.rs src/libstd/sys/common/wtf8.rs
2015-02-18rollup merge of #22287: Ryman/purge_carthographersAlex Crichton-5/+22
This overlaps with #22276 (I left make check running overnight) but covers a number of additional cases and has a few rewrites where the clones are not even necessary. This also implements `RandomAccessIterator` for `iter::Cloned` cc @steveklabnik, you may want to glance at this before #22281 gets the bors treatment
2015-02-18make FromIterator use IntoIteratorAlexis-2/+2
This breaks all implementors of FromIterator, as they must now accept IntoIterator instead of Iterator. The fix for this is generally trivial (change the bound, and maybe call into_iter() on the argument to get the old argument). Users of FromIterator should be unaffected because Iterators are IntoIterator. [breaking-change]
2015-02-18make Extend use IntoIteratorAlexis-1/+1
This breaks all implementors of Extend, as they must now accept IntoIterator instead of Iterator. The fix for this is generally trivial (change the bound, and maybe call into_iter() on the argument to get the old argument). Users of Extend should be unaffected because Iterators are IntoIterator. [breaking-change]
2015-02-18Fallout: iter, add markers or other changes such that all type parameters ↵Niko Matsakis-5/+6
are used.
2015-02-17Register new snapshotsAlex Crichton-23/+0
2015-02-17rollup merge of #22454: alexcrichton/stabilize-into-iteratorAlex Crichton-0/+5
Now that the necessary associated types exist for the `IntoIterator` trait this commit stabilizes the trait as-is as well as all existing implementations.
2015-02-18Remove usage of .map(|&foo| foo)Kevin Butler-4/+4
2015-02-18Opt for .cloned() over .map(|x| x.clone()) etc.Kevin Butler-1/+1
2015-02-18Implement RandomAccessIterator for ClonedKevin Butler-0/+17
2015-02-17std: Stabilize the IntoIterator traitAlex Crichton-0/+5
Now that the necessary associated types exist for the `IntoIterator` trait this commit stabilizes the trait as-is as well as all existing implementations.
2015-02-17Rollup merge of #22027 - iblech:patch-1, r=steveklabnikManish Goregaokar-2/+2
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.
2015-02-17Rollup merge of #22313 - japaric:iter, r=aturonManish Goregaokar-0/+25
`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
2015-02-17Rollup merge of #22344 - nagisa:exactsizediter, r=alexcrichtonManish Goregaokar-0/+1
Appears to be just an oversight given it is the only method in a stable trait. r? @aturon because you did final alpha stabilisation of iterators.
2015-02-15Stabilise ExactSizeIterator::lenSimonas Kazlauskas-0/+1
2015-02-13add an associated `Item` type to `IntoIterator`Jorge Aparicio-0/+25
2015-02-13Remove ExactSizeIterator from 64-bit ranges.Ulrik Sverdrup-2/+2
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]
2015-02-10rollup merge of #22125: alexcrichton/into-iter-stabilityAlex Crichton-7/+7
* 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).
2015-02-10rollup merge of #22065: bluss/range-size-hintAlex Crichton-10/+7
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.
2015-02-09std: Mark IntoIterator::into_iter as #[stableAlex Crichton-0/+1
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.
2015-02-09std: Rename IntoIterator::Iter to IntoIterAlex Crichton-3/+3
This is in preparation for stabilization of the `IntoIterator` trait. All implementations and references to `Iter` need to be renamed to `IntoIter`. [breaking-change]
2015-02-09std: Remove typarms from IteratorExt::clonedAlex Crichton-4/+3
With associated types an where clauses none of the type parameters are necessary. [breaking-change]
2015-02-08Fix std::ops::Range size_hint and ExactSizeIterator implsUlrik Sverdrup-10/+7
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.
2015-02-07Don't use std:: paths in syntax extensions when compiling a #![no_std] crateKeegan McAllister-1/+1
Fixes #16803. Fixes #14342. Fixes half of #21827 -- slice syntax is still broken.
2015-02-07Fix several tiny typosIngo Blechschmidt-2/+2
2015-02-04Fix for misspelled comments.Joseph Crail-1/+1
The spelling corrections were made in both documentation comments and regular comments.
2015-02-03rollup merge of #21907: alexcrichton/iter-by-refAlex Crichton-42/+19
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.
2015-02-03rollup merge of #21897: dotdash/rpositionAlex Crichton-3/+4
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) ````
2015-02-03std: Remove `iter::ByRef` and generalize implsAlex Crichton-42/+19
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]
2015-02-03Optimize rpositionBjörn Steinbrink-3/+4
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) ````
2015-02-02std: Add some missing stability attributesAlex Crichton-0/+2
* Display::fmt is stable * Debug::fmt is stable * FromIterator::from_iter is stable * Peekable::peek is stable
2015-02-02rollup merge of #21842: alexcrichton/issue-21839Alex Crichton-242/+108
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]
2015-02-02remove unused mut qualifiersJorge Aparicio-5/+5
2015-02-02`for x in xs.iter_mut()` -> `for x in &mut xs`Jorge Aparicio-2/+2
Also `for x in option.iter_mut()` -> `if let Some(ref mut x) = option`
2015-02-01std: Remove extra type params on iter adaptorsAlex Crichton-242/+108
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]
2015-02-01Auto merge of #21806 - edwardw:new-range-impl, r=alexcrichtonbors-69/+47
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 #21595 Closes #21649 Closes #21672
2015-02-01Make sure type inference with `a..b` as good as `range(a,b)`Edward Wang-69/+47
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 #21595 Closes #21649 Closes #21672
2015-01-31remove Copy impls from remaining iteratorsJorge Aparicio-0/+1
2015-01-30fixes after rebaseJorge Aparicio-1/+0
2015-01-30remove Copy impls from iteratorsJorge Aparicio-4/+3
2015-01-30fix falloutJorge Aparicio-9/+9
2015-01-30core: add the `IntoIterator` traitJorge Aparicio-0/+17
2015-01-29s/Show/Debug/gJorge Aparicio-1/+1
2015-01-29remove #[old_impl_check] now that #21363 has been fixedJorge Aparicio-2/+0
2015-01-29undo some conversionsJorge Aparicio-1/+1
2015-01-29`for x in range(a, b)` -> `for x in a..b`Jorge Aparicio-3/+3
sed -i 's/in range(\([^,]*\), *\([^()]*\))/in \1\.\.\2/g' **/*.rs