8 releases

0.2.1 Dec 10, 2018
0.2.0 Mar 10, 2019
0.1.6 Dec 10, 2018
0.1.5 Jul 16, 2018
0.1.1 May 20, 2016

#146 in Algorithms

Download history 64046/week @ 2021-02-26 63330/week @ 2021-03-05 66870/week @ 2021-03-12 66467/week @ 2021-03-19 67246/week @ 2021-03-26 69930/week @ 2021-04-02 69938/week @ 2021-04-09 70638/week @ 2021-04-16 70405/week @ 2021-04-23 66836/week @ 2021-04-30 77070/week @ 2021-05-07 75369/week @ 2021-05-14 68801/week @ 2021-05-21 73862/week @ 2021-05-28 74955/week @ 2021-06-04 72301/week @ 2021-06-11

289,717 downloads per month
Used in 558 crates (36 directly)


2.5K SLoC




"Fallible" iterators for Rust.


If the std or alloc features are enabled, this crate provides implementations for Box, Vec, BTreeMap, and BTreeSet. If the std feature is enabled, this crate additionally provides implementations for HashMap and HashSet.

If the std feature is disabled, this crate does not depend on libstd.


"Fallible" iterators.

The iterator APIs in the Rust standard library do not support iteration that can fail in a first class manner. These iterators are typically modeled as iterating over Result<T, E> values; for example, the Lines iterator returns io::Result<String>s. When simply iterating over these types, the value being iterated over must be unwrapped in some way before it can be used:

for line in reader.lines() {
    let line = line?;
    // work with line

In addition, many of the additional methods on the Iterator trait will not behave properly in the presence of errors when working with these kinds of iterators. For example, if one wanted to count the number of lines of text in a Reader, this might be a way to go about it:

let count = reader.lines().count();

This will return the proper value when the reader operates successfully, but if it encounters an IO error, the result will either be slightly higher than expected if the error is transient, or it may run forever if the error is returned repeatedly!

In contrast, a fallible iterator is built around the concept that a call to next can fail. The trait has an additional Error associated type in addition to the Item type, and next returns Result<Option<Self::Item>, Self::Error> rather than Option<Self::Item>. Methods like count return Results as well.

This does mean that fallible iterators are incompatible with Rust's for loop syntax, but while let loops offer a similar level of ergonomics:

while let Some(item) = iter.next()? {
    // work with item

Fallible closure arguments

Like Iterator, many FallibleIterator methods take closures as arguments. These use the same signatures as their Iterator counterparts, except that FallibleIterator expects the closures to be fallible: they return Result<T, Self::Error> instead of simply T.

For example, the standard library's Iterator::filter adapter method filters the underlying iterator according to a predicate provided by the user, whose return type is bool. In FallibleIterator::filter, however, the predicate returns Result<bool, Self::Error>:

# use std::error::Error;
# use std::str::FromStr;
# use fallible_iterator::{convert, FallibleIterator};
let numbers = convert("100\n200\nfern\n400".lines().map(Ok::<&str, Box<Error>>));
let big_numbers = numbers.filter(|n| Ok(u64::from_str(n)? > 100));

No runtime deps


  • alloc
  • std