Accept async functions for `StreamExt::map()` and others

[Sanskar Jaiswal]

The StreamExt::map(), StreamExt::filter_map() in the futures crate accepts async functions which resolve to an <T>/Option<T>, whereas the same methods in the futures-lite crate accept normal functions which are meant to return <T>/Option<T>. (there are other similar methods as well)

I don't know if this is by design or a mistake, but since this crate is supposed to be fully compatible with the futures crate, I think these methods should be changed accordingly.

[Taiki Endo]

The current behavior is what was intended by the original author of this crate.

rust-lang/futures-rs#1987 (comment)

since this crate is supposed to be fully compatible with the futures crate

Full compatibility is about traits such as streams, not about method signatures. Readme also says:

fixes minor warts in its API, fills in some obvious gaps

[Sanskar Jaiswal]

I see. Would adding async closures for these methods be considered? (especially if they don't affect compile times that much)

[John Nunley]

The usual strategy is to use the then() combinator to evaluate an async closure, and then use the result of that in filter_map(), map() etc.