future_form#

"This isn't even my final future form!"

Abstractions over Send and !Send futures in Rust.

The Problem#

Async Rust has a fragmentation problem: some runtimes require Send futures (like tokio), while others work with !Send futures (like Wasm). This forces library authors to either duplicate their async trait implementations or exclude legitimate use cases.

The Solution#

future_form lets you write async code once and support both Send and !Send futures:

use future_form::{FutureForm, Sendable, Local, future_form};
use std::marker::PhantomData;

trait Counter<K: FutureForm> {
    fn next(&self) -> K::Future<'_, u32>;
}

struct Memory<K> {
    val: u32,
    _marker: PhantomData<K>,
}

// Generates impl for both Sendable and Local
#[future_form(Sendable, Local)]
impl<K: FutureForm> Counter<K> for Memory<K> {
    fn next(&self) -> K::Future<'_, u32> {
        let val = self.val;
        K::from_future(async move { val + 1 })
    }
}

Packages#

See the future_form README for full documentation, usage patterns, and comparisons with async-trait and trait-variant.

Examples#

Design#

Architecture decisions and rationale are documented in design/.

License#

Licensed under either of Apache License, Version 2.0 or MIT license at your option.