/// If you're doing some sort of looping for a side effect, it's considered
/// more idiomatic to use [`for`] than `map()`.
///
- /// [`for`]: ../../book/loops.html#for
+ /// [`for`]: ../../book/first-edition/loops.html#for
///
/// # Examples
///
/// Creates an iterator that both filters and maps.
///
- /// The closure must return an [`Option<T>`]. `filter_map()` creates an
+ /// The closure must return an [`Option<T>`]. `filter_map` creates an
/// iterator which calls this closure on each element. If the closure
/// returns [`Some(element)`][`Some`], then that element is returned. If the
/// closure returns [`None`], it will try again, and call the closure on the
/// next element, seeing if it will return [`Some`].
///
- /// Why `filter_map()` and not just [`filter()`].[`map`]? The key is in this
+ /// Why `filter_map` and not just [`filter`].[`map`]? The key is in this
/// part:
///
/// [`filter`]: #method.filter
///
/// In other words, it removes the [`Option<T>`] layer automatically. If your
/// mapping is already returning an [`Option<T>`] and you want to skip over
- /// [`None`]s, then `filter_map()` is much, much nicer to use.
+ /// [`None`]s, then `filter_map` is much, much nicer to use.
///
/// # Examples
///
/// use a `for` loop with a list of things to build up a result. Those
/// can be turned into `fold()`s:
///
- /// [`for`]: ../../book/loops.html#for
+ /// [`for`]: ../../book/first-edition/loops.html#for
///
/// ```
/// let numbers = [1, 2, 3, 4, 5];
/// Stopping at the first `true`:
///
/// ```
- /// let a = [1, 2, 3];
+ /// let a = [1, 2, 3, 4];
///
/// let mut iter = a.iter();
///
- /// assert_eq!(iter.position(|&x| x == 2), Some(1));
+ /// assert_eq!(iter.position(|&x| x >= 2), Some(1));
///
/// // we can still use `iter`, as there are more elements.
/// assert_eq!(iter.next(), Some(&3));
+ ///
+ /// // The returned index depends on iterator state
+ /// assert_eq!(iter.position(|&x| x == 4), Some(0));
+ ///
/// ```
#[inline]
#[stable(feature = "rust1", since = "1.0.0")]