Repository navigation
What degree of panic safety is expected for iterator adapters? #58170
Description
What state(s) are iterator adapters allowed to be in after a panic, @rust-lang/libs? Obviously they need to memory safe, but how many items are they expected to have consumed? Is it even allowed to call .next() on an (un-fused) iterator after you called, say, .find() on it with a closure that panicked?
Asking because this has just come up in two PRs:
Activity
sfackler commentedon Feb 5, 2019
I think I personally see this as an edge case a bit like leaking
vec::Drainand the like. We definitely need to avoid allowing memory unsafety, but otherwise I think it's reasonable for the iterator to be in an unspecified state.nextcould continue to return values, it could return None, etc. In particular, I'd be fine with this behavior changing over time based on how we adjust the iterator's internal implementation.alexcrichton commentedon Feb 5, 2019
I personally feel the same way as @sfackler, I don't think we need to hold ourselves to any particular standard in the standard library other then "stay memory safe"
dtolnay commentedon Feb 6, 2019
I agree. I would like for this to be called out briefly in the std::iter module doc, which currently does not mention panic.
Rollup merge of rust-lang#67564 - Mark-Simulacrum:iter-adapter-panic,…