What degree of panic safety is expected for iterator adapters?

[scottmcm]

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:

• RangeInclusive internal iteration performance improvement. #58122 (comment)
• override VecDeque::try_rfold, also update iterator #58064 (comment)

[sfackler]

I think I personally see this as an edge case a bit like leaking vec::Drain and 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. next could 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]

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]

I agree. I would like for this to be called out briefly in the std::iter module doc, which currently does not mention panic.