I’m trying to design a simple API for iterating over values retrieved from a file. I’d like to point my users to std::Iterator and be done with it. Unfortunately (but correctly!), my iterator’s Item type is io::Result<u64>, so I need to deal with the possibility of an Err at each step. I don’t want the code to panic and I’d like to stop processing as soon as an Err is encountered.

What I’m after is something like this:

let answer: Result<u64, io::Error> = input
.iter()
.take(10)
.sum();

In many contexts I can use the ? operator to short-circuit processing when an Err variant of Result is encountered, but there doesn’t seem to be an equivalent for working with Iterator.

I’m aware of partition(), but the input could be quite long. I don’t want to continue pulling from the iterator after the first Err is returned.

I’m aware of collect(), but users will only very rarely want to collect() the values they’re reading. It’s much more likely that they’ll want to process them as they go, avoiding allocation.

I’m aware of try_fold() and try_for_each(), but these won’t allow me to use the Iterator API – I’ll have to fully define the processing for each individual value within a lambda. At that rate, I may as well use a for loop instead of an iterator.

True, you can’t unwrap arbitrary Iterator methods this way. I’ll bet you can almost always approximate this with other methods, especially try_fold, but you’re right it won’t be as nice as the ? operator.

I just found @sfackler’s fallible-iterator crate, which appears to offer a version of the Iterator trait that does exactly this! I’ll have to try it out, curious to know whether there’s any performance overhead.