Breaking down what async fn in trait does, it converts it to a fn method() -> impl Future<Output=T>, which breaks further down into fn method() -> Self::__MethodRet where the generated associated type implements Future.

This doesn’t work for dyn Trait because of the associated type (and the fact method() needs a dyn-safe self parameter).

Instead, your methods need to return dyn Future in some capacity since that return type doesn’t rely on associated types. That’s where async_trait comes in. Box<dyn Future<...>> is a dyn-safe boxed future, then it’s pinned because async usually generates a self-referential type, and you need to pin it anyway to .poll() the resulting future.

Edit: also, being pedantic, associated types are fine in dyn traits, but you need to specify the type for it (like dyn Blah<Foo=i32>. Even if you could name the return type from an async fn, it’d be different for every impl block, so that’s not realistic here.

If I understand what you’re asking…

This leaves out some details/specifics out to simplify. But basically:

async fn foo() {}

// ^ this roughly desugars to

fn foo() -> impl Future<()> {}

This meant that you couldn’t just have (stable) async methods in traits, not because of async itself, but because you couldn’t use impl Trait in return positions in trait methods, in general.

Box<dyn Future> was an unideal workaround (not zero-cost, and other dyn drawbacks). async_trait was a proc macro solution that generated code with that workaround. so Box<dyn Future> was never a desugaring done by the language/compiler.

now that we have (stable) impl Trait in return positions in trait methods, all this dance is not strictly needed anymore, and hasn’t been needed for a while.

Oh I was in your position like A month ago… You’re gonna love dealing with Dyn compatibility and Async. I lost half of my hair because I kept pulling on it and smashing my head against the wall

I’m not informed on all the details, but a key difference between the async_trait macro and a native async keyword is that async_trait gives you that boxed, trait object type. IIUC the thinking is native support should not automatically box futures, which implies it shouldn’t use dyn either. Using Box and dyn is an easy way to make sure the code works no matter what type of future a method returns. But the trade-off is some runtime overhead from heap allocation (due to Box), and dynamic dispatch (due to dyn).

According to areweasyncyet.rs:

async fn in trait method not stabilized yet

• Workaround is available as an attribute macro: async-trait