v2.4.0

[notgull]

• Add a "fuse" method that makes it so a Future returns Poll::Pending forever after it returns Poll::Pending once. (#101)
• Add a "stop_after_future" function that allows for running a Future until a Stream completes. (#103)

[taiki-e]

• a "take_until" method

• It seems that what was actually added was an freestanding function (stream::take_until) not a trait method (StreamExt::take_until)? (The PR title and commit message also says StreamExt::take_until)
• The Iterator::take_while takes FnMut(&Self::Item) -> bool as a predicate. I don't remember if futures had the same method but maybe it takes Fn* which returns a future. Is there any reason why ours decided to take a future compared to those?

[notgull]

Good catch! I forgot to check the equivalent Iterator method, I'll fix.

[notgull]

Actually, on second check I think it's intentional. The idea is "run a stream in parallel with a future and stop the stream when the future stops." I think the idea is this:

let my_stream = /* ... */;
let (signal, shutdown) = async_channel::bounded::<()>(1);

// Send the shutdown signal when the user hits ctrl-c.
executor.spawn(async move {
    wait_for_user_to_hit_ctrl_c().await;
    signal.try_send(()).ok();
}).detach();

// Run until the stream stops.
while let Some(item) = stream::take_until(my_stream, shutdown).next().await {
    do_something(item).await;
}

[taiki-e]

(Honestly, I have no strong opinion on which API to choose here. I just know what the result of inconsistent APIs can be: https://github.com/rust-lang/futures-rs/issues/2755)

[notgull]

I think it's not an inconsistent API, since it's somewhat Stream-specific. However I would be okay with changing the name to distinguish it from any Iterator functions.

[notgull]

I think the name is the core point of confusion here. I've opened #104 to address this.

[notgull]

I've changed the name,