smol-rs / futures-lite

Futures, streams, and async I/O combinators.
Apache License 2.0
439 stars 25 forks source link

Provide an `or!` macro that handles any number of futures #7

Open joshtriplett opened 4 years ago

joshtriplett commented 4 years ago

This has the same effect as f1.or(f2.or(f3.or(...))) but without the nesting.

Note that an equivalent race! macro would not be fair, since it would be a coin-flip at each level. A fair race! macro would need to count the number of futures, and select randomly. This could be done by adding a version of the Race future that has a count and checks its first future first with 1/N probability, and its second future first otherwise.

joshtriplett commented 4 years ago

@stjepang That's doable. Could you live with it appearing as both futures_lite::or_futures! (or similar placeholder) and as futures_lite::future::or!? (The alternative would, as far as I can tell, require a separate helper crate.)

ghost commented 4 years ago

Hmm, I would be okay with a helper crate, perhaps futures-lite-macros that would allow us to export the macro into the right module. It's not like such a crate would materially impact compilation times, and I expect in the future rust version the hack will not be necessary.

joshtriplett commented 4 years ago

Alright, I can try that. (It'd look a lot like this, but with the macro implementations moved to that helper crate, and then pub used here.)

ghost commented 4 years ago

Sounds good!

jjl commented 4 years ago

I loved this so much I stole it for futures-micro. Also I adapted it for zip/join with mildly amusing results

jjl commented 4 years ago

You could actually just depend on futures-micro to get this macro now it's released, instead of extracting it out into a new crate. You'd also get an implementation of PollFn (which is itself about a third of the crate size), and i was suggesting you nick PollState anyway, which is another third of it.

ghost commented 4 years ago

That’s actually a good idea :)

joshtriplett commented 4 years ago

@jjl: I think the implementation of zip should pattern-match out of the nested 2-tuples, and emit an N-tuple. That isn't hard to do in a macro, and it would substantially improve usability.

jjl commented 4 years ago

i completely agree, I just haven't gotten around to figuring it out yet.

jjl commented 4 years ago

now done

jacobrosenthal commented 4 years ago

I would use this :)

jjl commented 4 years ago

you already can, it's in the released futures-micro

jacobrosenthal commented 4 years ago

I am using it, id be happy to see a reexport if that happens.

On Wed, Aug 26, 2020 at 10:11 PM jjl notifications@github.com wrote:

you already can, it's in the released futures-micro

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stjepang/futures-lite/pull/7#issuecomment-681496290, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADPI5BFTTU7ABAIZOUEV4TSCXTG7ANCNFSM4PU5A2ZA .

jjl commented 4 years ago

there's a PR for that! #15

notgull commented 1 year ago

Is there still any interest in this?

Personally I'm a fan of the fact that futures-lite doesn't contain any obscure macros right now, and I think that a.or(b).or(c) looks better than or!(a, b, c). Still, it looks like people were interested in this above, so there might still be demand for it now.

taiki-e commented 1 year ago

a.or(b).or(c)

I think such a chain is basically an anti-pattern because polling will become unfair. https://github.com/tokio-rs/tokio/issues/2319