3 ms·

Yeah, it's expected this year: https://blog.rust-lang.org/inside-rust/2023/05/03/stabilizing-async-fn-in-trait.html https://blog.rust-lang.org/inside-rust/2023/

• qaq 3y ago
  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
  • hgomersall 3y ago
    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.
    • qaq 3y ago
      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
      • hgomersall 3y ago
        That will work. It only needs the additional bounds if you want to spawn that as a new task.
        • qaq 3y ago
          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?
          • jen20 3y ago
            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.