Provide an or! macro that handles any number of futures

[joshtriplett]

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.

[ghost]

This looks good, thank you!

I kind of wish the or! macro appeared in the future module rather than in the crate root. It might a bit tricky to achieve that though. What do you think?

[joshtriplett]

@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]

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]

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]

Sounds good!

[jjl]

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

[jjl]

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]

That’s actually a good idea :)

[joshtriplett]

@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]

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

[jjl]

now done

[jacobrosenthal]

I would use this :)

[jjl]

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

[jacobrosenthal]

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

…

On Wed, Aug 26, 2020 at 10:11 PM jjl ***@***.***> 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 <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADPI5BFTTU7ABAIZOUEV4TSCXTG7ANCNFSM4PU5A2ZA> .

[jjl]

there's a PR for that! #15

[notgull]

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]

a.or(b).or(c)

I think such a chain is basically an anti-pattern because polling will become unfair. tokio-rs/tokio#2319