> ## Documentation Index > Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt > Use this file to discover all available pages before exploring further. # Rust Async Function An asynchronous function in Rust, declared using the `async fn` keyword, is syntactic sugar for a function that returns a state machine implementing the `std::future::Future` trait. Rather than executing synchronously and returning a computed value, an `async fn` defers execution, immediately returning an opaque, compiler-generated type. The actual body of the function is only evaluated when this returned `Future` is actively polled by an asynchronous executor. ```rust theme={"dark"} // Standard async function declaration async fn compute_value(x: u32) -> u32 { x + 1 } // Conceptual desugaring by the Rust compiler fn compute_value_desugared(x: u32) -> impl std::future::Future { async move { x + 1 } } ``` ## The Execution Model: Lazy Evaluation In Rust, futures are strictly lazy. Invoking an `async fn` performs no work and consumes no CPU cycles for the function body. It merely constructs the initial state of the future. To drive the future to completion, it must be passed to an executor (a runtime component) that repeatedly calls the `poll` method defined by the `Future` trait. ## The `.await` Operator Within the body of an `async fn`, the `.await` postfix operator is used to suspend execution. When `.await` is called on an inner future, it checks if that future is ready: * If `Poll::Ready(value)` is returned, execution continues synchronously. * If `Poll::Pending` is returned, the current `async fn` yields control back to the executor, suspending its own execution until the underlying task registers a wakeup notification (via a `Waker`). ```rust theme={"dark"} async fn process_data() -> u32 { let step_one = compute_value(10).await; // Yield point 1 let step_two = compute_value(step_one).await; // Yield point 2 step_two } ``` ## State Machine Transformation Under the hood, the Rust compiler transforms the body of an `async fn` into a state machine represented by an anonymous `enum`. Each `.await` expression represents a yield point and a distinct state transition. Local variables that must survive across an `.await` point are stored within the variants of this generated `enum` rather than on the standard thread stack. This allows the function to be suspended and later resumed with its exact local state preserved. ## Pinning and Self-Referential Structs Because local variables are stored inside the generated state machine, an `async fn` can easily create self-referential structs. For example, if a reference to a local variable is held across an `.await` point, the state machine contains both the data and a pointer to that data. To guarantee memory safety and prevent these internal pointers from being invalidated by memory moves, the `Future` generated by an `async fn` must be pinned in memory using `std::pin::Pin` before it can be polled. The executor handles this pinning process, ensuring the state machine cannot be moved in memory once execution begins. ## Trait Implementation Constraints Historically, `async fn` could not be used directly inside traits because traits could not return unboxed, anonymous types. As of Rust 1.75, `async fn` in traits (AFIT) is natively supported. The compiler automatically desugars trait-level async functions into returning an `impl Future`, though dynamic dispatch (`dyn Trait`) with async functions still requires type erasure (e.g., boxing the future) due to the lack of a known size at compile time.

Tired of Poor Rust Skills? Fix That With Deep Grasping! Learn More