Make macro_rules (try_)join! always available

[NobodyXu]

Motivation

It does not use anything from tokio-macros, thus gating it behind feature macros does not make sense.

It forces users who have to use tokio::{try_join, join} to enable feature macros and pull in crate tokio-macros, which is unnecessary.

Solution

Make tokio::{try_join, join} always available regardless of whether feature macros is enabled.

[taiki-e]

This will prevent {try_,}join from relying on tokio-macros in the future.

Historically, we have used tokio-macros to handle problems that cannot be handled well by declarative macros (#4211), but I'm not certain that {try_,}join will not encounter such problems in the future.

See also #4804.

[NobodyXu]

Historically, we have used tokio-macros to handle problems that cannot be handled well by declarative macros (#4211), but I'm not certain that {try_,}join will not encounter such problems in the future.

I don't think so, given that tokio already reaches v1.0.0, I don't think it will change the semantics of tokio::{try_, }join that will require such dramatic change to the point of requiring proc-macro.

[taiki-e]

I meant bugfixes like #4211 (tokio-1.14.0), not semantics changes.

That said, as long as it is not breaking, we can add a new syntax or feature in 1.x, like #3603 (tokio-1.4.0).

[NobodyXu]

I meant bugfixes like #4211 (tokio-1.14.0), not semantics changes.

That said, as long as it is not breaking, we can add a new syntax or feature in 1.x, like #3603 (tokio-1.4.0).

I don't think tokio::{try, }join will need a proc-macro to fix a bug, given that it is actually not that complicated compared to tokio::select!.

tokio::select! needs to be able to parse pattern, branches, etc, but join! and try_join! does not.

They just need to take futures (expressions), polling for all of them to complete and for try_join! it also needs to propagate the error, but it really doesn't sound like they would need proc-macro for parsing.

Though futures-util does seem to forward their {try, }join! straight to futures-macro.

[carllerche]

There is more than just fixing bugs. We may, in the future, want to use proc macros to provide better errors or additional features. If you wish to use the macro as is today w/o syn, you can always pull it out yourself in a separate crate or just copy the code in your app/crate.