Rust 1.75 Async Fn in Traits vs async-trait Crate

How the compiler treats Send for native async trait methods

In Rust 1.75 an async fn in a trait desugars to a method that returns an opaque type implementing Future. The compiler does **not** automatically add a Send bound to that future, nor does it box the return type. When the trait is used through a trait object (dyn Trait) the caller must know the concrete future type unless you explicitly erase it.

Achieving the same erasure as async-trait

To get the erase‑and‑box behaviour that the async-trait macro provided, you need to make the trait method return a boxed, send‑able future yourself. The pattern is:

1. Declare the trait method to return Pin + Send>> (or the same without + Send if the future never crosses threads).
2. In each implementation, build the async block and wrap it with Box::pin.
3. Call the method through the trait object exactly as before; the returned future is already boxed and ready to be .awaited.

use std::pin::Pin;
use std::future::Future;

trait MyTrait {
    fn method(&self) -> Pin> + Send>>;
}

impl MyTrait for MyStruct {
    fn method(&self) -> Pin> + Send>> {
        Box::pin(async move {
            // async work here
            Ok(())
        })
    }
}

fn use_it(obj: &dyn MyTrait) {
    // obj.method() returns a Pin>
    // .await works directly
    let _ = obj.method().await;
}

If you are certain the trait objects will never be sent between threads, you can drop the + Send from the return type and the trait object itself, which avoids the unnecessary boxing overhead.

When to ask for more detail

The only diagnostic detail that changes the recommendation is whether the trait objects must be Send (i.e., used across thread boundaries). If they do not need to be Send, you can omit the + Send bound and the associated boxing, keeping the zero‑cost abstraction. Please confirm if your use case requires Send on the trait objects.