# `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:

```rust
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

| Crate | Description |
|-------|-------------|
| [`future_form`](./future_form) | Core traits and types (`FutureForm`, `Sendable`, `Local`) |
| [`future_form_macros`](./future_form_macros) | The `#[future_form]` attribute macro |

See the [`future_form` README](./future_form/README.md) for full documentation, usage patterns, and comparisons with `async-trait` and `trait-variant`.

## License

Licensed under either of [Apache License, Version 2.0](LICENSE-APACHE) or [MIT license](LICENSE-MIT) at your option.