You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this iterator would be a wrapper for iterator.process_results(|items| items.map(|item| item)) when either raising the first error, or successfully raising an impl Iterator<Item = Result<T, E>> into a Result<impl Iterator<Item = T>, E>.
I find this particularily useful when using iterator.collect::<Result<Vec<_>, _>>() or likewise is not possible, say with a custom allocator (as collect_into does not to collect into a result of items at the moment) or in a nostd context. This would also provide a more ergonomic way of using the aforementioned proces_results adapter
The text was updated successfully, but these errors were encountered:
The issue here is that to get a Result, we need to consume (at least partially) the iterator and therefore collect the intermediary Ok elements, which necessarily allocate. Something like
this iterator would be a wrapper for
iterator.process_results(|items| items.map(|item| item))
when either raising the first error, or successfully raising animpl Iterator<Item = Result<T, E>>
into aResult<impl Iterator<Item = T>, E>
.I find this particularily useful when using
iterator.collect::<Result<Vec<_>, _>>()
or likewise is not possible, say with a custom allocator (as collect_into does not to collect into a result of items at the moment) or in a nostd context. This would also provide a more ergonomic way of using the aforementioned proces_results adapterThe text was updated successfully, but these errors were encountered: