FuturesUnordered + HashMap?

[allsey87]

I would like to have something like FuturesUnordered but where the collection behaves more like a HashMap (so that I can easily look up a future by its key instead of using .iter().find() etc). Has this been considered and if so, is there any reason this doesn't exist?

I guess there is a good reason why the following also doesn't exist, but it would be awesome if somehow FuturesOrdered and FutureUnordered could have been traits that were automatically implemented for any collection where the stored type implements Future.

[taiki-e]

I think it's a good idea to add something like a map.
In particular, there is currently no way to remove a specific future from the FuturesUnordered.

[bootrecords]

I'd think one could obtain that kind of behaviour with tokio's StreamMap, but of course might not hurt to have a structure more geared towards Futures as compared to Streams.

[ibraheemdev]

Would it be better to modify FuturesUnordered or add a new FutureMap type? The latter would probably be much easier.

[taiki-e]

The latter would probably be much easier.

Yeah. I would prefer the latter.

[mitinarseny]

Really looking forward to use it

[StoicDeveloper]

I went ahead and wrote a library based on FuturesUnordered that does exactly this: https://github.com/StoicDeveloper/mapped_futures. I aim to publish it as a crate once I have some feedback.

[StoicDeveloper]

Here is the crate that covers this issue: https://crates.io/crates/mapped_futures

[allsey87]

@StoicDeveloper what was the motivation for making a separate crate instead of opening a PR, here?

[StoicDeveloper]

@StoicDeveloper what was the motivation for making a separate crate instead of opening a PR, here?

@allsey87 Honestly, it had not occurred to me to do so. I haven't really contributed to open source projects before. Mostly, I wanted to start using the feature immediately, whereas opening a PR would involve more discussion and require approval by the owners of this repo by meeting their standards, though of course that would be a very good thing for verifying the soundness of my unsafe changes as well as ensuring the code's quality. I think my task next will be to do just that.

[thomaseizinger]

We had a similar need with the added requirements of bounding the Futures and Streams in their execution time and also capping the size of how many are allowed to execute at any one time.

In case it is of interest, the code is here: https://github.com/libp2p/rust-libp2p/tree/master/misc/futures-bounded/src.