Yeah, it's expected this year: https://blog.rust-lang.org/inside-rust/2023/05/03/stabilizin...

async fn do_health_check_par<HC>(hc: HC) where HC: HealthCheck + Send + 'static, HC::check(): Send, // <-- associated return type { tokio::task::spawn(async move { if !hc.check().await { log_health_check_failure().await; } }); }

Hmm I think for 95% of the people sticking to something like Swift would work out better for them

Are you saying 95% of use cases require spawning new tasks within the trait implementation based on argument futures? Or are you making a more general comment about rust generics? The MVP looks about as clean as I could hope for most use cases.

I am saying that in web services you will frequently use async functions that look like async fn do_blah(db_repo: impl DBRepo ...) {...} and are executed on async-std or Tokio

That will work. It only needs the additional bounds if you want to spawn that as a new task.

so if I am doing async calls on DBRepo inside that function they can not be moved to a different thread by a runtime like tokio?

One would typically not spawn those - as I understand it you need the type constraints if calling “tokio::spawn” (or some equivalent) but not if simply calling an async function in the same task.

Why is the macro not a solution?

don't you have like extra heap allocation per call with code that macro expands to?