Rust 1.75 async traits leave threading guarantees to API authors

Rust 1.75.0 is available, bringing native asynchronous methods to traits. The December 28 release also lets trait methods return an unnamed type through -> impl Trait. Together, those changes make asynchronous interfaces easier to express, while leaving library authors responsible for a consequential compatibility decision.

An async fn returns a future. In a trait, the new syntax hides that future’s concrete type, just as an iterator-returning method can hide its implementation behind impl Iterator. The difficult part is what downstream code can require from the hidden result.

Rust logo: Rust Foundation, from the official artwork repository, CC BY 4.0. Proportional rasterization and white padding; logo artwork unchanged. Rust is a trademark of the Rust Foundation. Sulat isn’t affiliated with or endorsed by the Foundation or Rust Project.

A threading guarantee belongs in the interface

The Async Working Group’s December 21 explanation warns that callers can’t add arbitrary bounds to these return types in generic code. An iterator might support reverse traversal in one implementation, for example, without the trait promising that capability to every caller.

For async libraries, the important case is Send: whether the returned future can move between threads. Code spawning work on a multithreaded, work-stealing executor can need that guarantee even when a simpler direct call works.

A bare public async method doesn’t promise a Send future. Rust therefore warns about this form in public traits. An author can spell out a method returning impl Future + Send, but that becomes part of the API contract. Removing the guarantee later can break callers that rely on it.

This makes the migration question more specific than whether a project compiles on 1.75. The trait has to express the guarantees its consumers need, including consumers the author hasn’t written.

Two variants help, within limits

The working group recommends its separately published trait-variant procedural macro for libraries that want to offer a choice. It can generate a Send version alongside a local version permitting non-Send futures. The stronger version adds a bound to the trait and its returned futures; it doesn’t make an incompatible implementation safe to move between threads.

The group’s contemporary crate announcement predates the compiler release. This is a library-assisted design pattern, rather than automatic executor selection by Rust.

There’s also a composability limit. The December explanation says this variant approach can’t conditionally implement the Send variant based on a generic parameter, a problem that can arise in middleware wrapping another service.

Dynamic dispatch remains a separate migration gate

Native async trait methods still don’t support calls through dyn Trait. The stabilization report records a narrower exception: marking a method Self: Sized can keep the surrounding trait object-safe by excluding that method from the object’s dispatch table. It doesn’t make that method callable through the trait object.

Consequently, generating a Send variant doesn’t solve dynamic dispatch. The working group still identifies dynamic dispatch and support for Rust versions before 1.75 as reasons to retain the async-trait macro. Its proposed dynamic-dispatch utilities for trait-variant remain future work in this release.