Drop async_trait

[matze]

Motivation

This change was born mostly out of curiosity rather than a serious attempt to get it in any time soon. The main motivation of course is to get rid of the async_trait macro and boxed futures in favor of recently stabilized async fn in traits.

Solution

Remove usage of the async_trait macro and adjust the server codegen parts to return desugared impl Future<…> + Send because of the Send bound problem.

Caveats

This requires a nightly compiler but with that passes all tests as well as some manual tests I performed.

The larger question to answer though is how this would be merged into tonic eventually. tonic-health and tonic-reflection rely on generated code which prohibits a gradual, feature-based integration. Moreover, this would require quite a large bump of MSRV to 1.75.

[LucioFranco]

@matze Nice! I think we could potentially offer this as an opt-in during codegen? I don't think there is anything stopping us from support both since its mostly codegen and user callsite code that is affected. What do you think?

[matze]

If I understand correctly and in order to have mid-term compatibility means adding a separate flag async_trait that is automatically enabled with codegen? Even easier, if codegen is on but async_trait not, then this one here could kick in. Should indeed make the PR much smaller as well and be green. Let me try :-)

[matze]

@LucioFranco I tested but the initial caveat still holds, all crates using pre-generated services require either async_trait or a nightly compiler. And emitting code with the feature flag check in place does not work either.

[matze]

A similar PR is approved for axum, how do you think just breaking as well?

[LucioFranco]

@LucioFranco I tested but the initial caveat still holds, all crates using pre-generated services require either async_trait or a nightly compiler. And emitting code with the feature flag check in place does not work either.

I am not following what you mean by this?

A similar tokio-rs/axum#2308 is approved for axum, how do you think just breaking as well?

I think we should if we can get it so it works for both and users can choose.

[matze]

I am not following what you mean by this?

I mean I don't see how this could ever work for both. tonic-health and tonic-reflection contain pre-generated implementations that either fit a hypothetical feature flag that represents async-trait-less tonic or not. I mean we could go back to the times when tonic-health and tonic-reflection were generated at build time but I guess you had good reasons to not do so.