See here and the following comment for an explanation. (Your case is a little simpler because there's no method receiver.) Or rephrased: T can never represent the future returned from your closure, because that future captures a lifetime -- it's parameterized by the input lifetime; it's not a single type.
There are a couple other hurdles to your OP:
- Your closure also captuers a
&muttobaz. Was that intentional?- If so, complicates things -- now there's another lifetime at play
- Even if you don't need that, Rust's inference of closures you want to be higher-ranked is pretty bad
Here's a playground for the case where you don't need to capture a &mut baz. It demonstrates the second hurdle too.
If there's a way around the first bullet point without boxing, I think it'd run into the second bullet point too -- and not have a workaround using async fn.