File tree 1 file changed +3
-3
lines changed
1 file changed +3
-3
lines changed Original file line number Diff line number Diff line change @@ -518,13 +518,13 @@ pub trait Iterator {
518
518
519
519
/// Creates an iterator that both filters and maps.
520
520
///
521
- /// The closure must return an [`Option<T>`]. `filter_map() ` creates an
521
+ /// The closure must return an [`Option<T>`]. `filter_map` creates an
522
522
/// iterator which calls this closure on each element. If the closure
523
523
/// returns [`Some(element)`][`Some`], then that element is returned. If the
524
524
/// closure returns [`None`], it will try again, and call the closure on the
525
525
/// next element, seeing if it will return [`Some`].
526
526
///
527
- /// Why `filter_map() ` and not just [`filter() `].[`map`]? The key is in this
527
+ /// Why `filter_map` and not just [`filter`].[`map`]? The key is in this
528
528
/// part:
529
529
///
530
530
/// [`filter`]: #method.filter
@@ -534,7 +534,7 @@ pub trait Iterator {
534
534
///
535
535
/// In other words, it removes the [`Option<T>`] layer automatically. If your
536
536
/// mapping is already returning an [`Option<T>`] and you want to skip over
537
- /// [`None`]s, then `filter_map() ` is much, much nicer to use.
537
+ /// [`None`]s, then `filter_map` is much, much nicer to use.
538
538
///
539
539
/// # Examples
540
540
///
You can’t perform that action at this time.
0 commit comments