`take_until` and `map_until`

[JohnScience]

A while ago there was a proposal by Jon Gjengset (jonhoo) to add take_until into Rust's standard library:
rust-lang/rust#62208

While it may be not a good fit for the standard library, it might be a worthwhile addition to itertools.

As michaelsproul pointed out in the discussion,

I don't think take_while_ref or peeking_take_while are well suited to this because they require you to assign the iterator to a local variable, and muck around with mutation, which breaks the flow of the iterator chain. The best I could do with them was this, which isn't as nice as take_until.

If you don't mind, I'd be happy to try and get your code into itertools, giving you credit of course! (Co-authored-by on the commit)

[Samyak2]

I would like to take this up.

I needed this functionality for a project but noticed that this is neither present in the standard library nor itertools.

[junbl]

I'm curious how y'all envision a map_until function would work.

The difference between take_while and take_until being that we keep the first element for which the predicate isn't satisfied, what would we do with that first non-satisfying element in the map version? I'm assuming that the setup is the same as map_while and we're passing a function (I::Item) -> Option<T>. We can't return it unchanged, since it'll likely be of the wrong type, and we don't have a T since it returned None.

Maybe a map_while_ref would fit that use case better?

[junbl]

I've been thinking about it, and I think the take_until name is confusing, as it implies a reversal of the predicate (take until this is satisfied vs. take while this is satisfied) which is unrelated to the actual functionality. take_while_inclusive more clearly shows the relationship with the existing method and the purpose of this adaptor.

[musjj]

Did map_until ever made it? My use-case is that I wanted to have something like map_while that allows me to return one last value before stopping the iterator. With Option<T>, this isn't possible. It could instead be modeled using a custom enum like:

pub enum ControlFlow<T> {
    Continue(T),
    Stop(T),
}