Open aryan9600 opened 2 years ago
The current behavior is what was intended by the original author of this crate.
https://github.com/rust-lang/futures-rs/issues/1987#issuecomment-661028051
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
I see. Would adding async closures for these methods be considered? (especially if they don't affect compile times that much)
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.
The
StreamExt::map()
,StreamExt::filter_map()
in thefutures
crate accepts async functions which resolve to an<T>
/Option<T>
, whereas the same methods in thefutures-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.