Why does `StreamExt::filter` and `StreamExt::filter_map` require functions that returns futures

[jannickj]

Currently looking at the api spec the functions for StreamExt::filter takes a function that must return a future, however in 99% of cases you just want to filter on the data, so why needlessly bloat the code with future::ready, instead of having a dedicated function if this is really necessary (which i doubt).

I can understand it being useful to have a function which takes futures, but filter and filter_map are very unexpected to require futures.

It just feels like someone was a bit trigger happy on the merge button.

[tgiddings]

It's less of a requirement and more of an allowance. A non-future callback can be transformed to a future callback easily. The reverse is generally impossible. Changing these functions to use non-future callbacks would greatly reduce their capabilities.

You could make a case for separate filter* and filter*_async methods. I'm not sure the split is worthwhile though.

[jannickj]

The thing is there are tons of ways to solve that problem, example: .and_then([async code]).filter_map(|x| x), the problem I have with this api design is that it's inconsistent and makes the code harder to parse because filter_map's behavior is different when applied to a stream.

If I may make a shameless plug, this is one of my gripes with the futures crate that have pushed me to fork it: https://docs.rs/futures-lite This fork is just smaller with minor differences and compiles faster, but is still compatible with futures.

Some functionality is still missing (like filter_map()) but I'll add the remaining missing stream combinators over the next couple days. I also don't like async closures in stream combinators, which is why e.g. my fold() doesn't take an async closure, unlike the fold() method in futures.

[taiki-e]

Closing in favor of #2755.