Lines Matching full:async
1 # maybe-async
3 **Why bother writing similar code twice for blocking and async code?**
5 …ps://github.com/fMeow/maybe-async-rs/workflows/CI%20%28Linux%29/badge.svg?branch=main)](https://gi…
7 …test Version](https://img.shields.io/crates/v/maybe-async.svg)](https://crates.io/crates/maybe-asy…
8 [](https://docs.rs/maybe-async)
10 When implementing both sync and async versions of API in a crate, most API
11 of the two version are almost the same except for some async/await keyword.
13 `maybe-async` help unifying async and sync implementation by **procedural
15 - Write async code with normal `async`, `await`, and let `maybe_async`
17 those `async` and `await` when you need a blocking code.
18 - Switch between sync and async by toggling `is_sync` feature gate in
33 version (one async and another blocking) can fail compilation.
38 The async/await language feature alters the async world of rust.
39 Comparing with the map/and_then style, now the async code really resembles
42 In many crates, the async and sync version of crates shares the same API,
43 but the minor difference that all async code must be awaited prevent the
44 unification of async and sync code. In other words, we are forced to write
45 an async and a sync implementation respectively.
49 `maybe-async` offers 4 set of attribute macros: `maybe_async`,
52 To use `maybe-async`, we must know which block of codes is only used on
53 blocking implementation, and which on async. These two implementation should
54 share the same function signatures except for async/await keywords, and use
57 Use `maybe_async` macro on codes that share the same API on both async and
58 blocking code except for async/await keywords. And use feature gate
59 `is_sync` in `Cargo.toml` to toggle between async and blocking code.
63 Offers a unified feature gate to provide sync and async conversion on
64 demand by feature gate `is_sync`, with **async first** policy.
66 Want to keep async code? add `maybe_async` in dependencies with default
74 Want to convert async code to sync? Add `maybe_async` to dependencies with
87 to support async fn in traits.
91 Not all async traits need futures that are `dyn Future + Send`.
93 to avoid having "Send" and "Sync" bounds placed on the async trait
100 …For compatibility reasons, the `async fn` in traits is supported via a verbose `AFIT` flag. This w…
105 **Keep async**.
114 **Convert to sync code**. Convert the async code into sync code by
115 removing all `async move`, `async` and `await` keyword
121 must simply disappear when we want async version.
124 point when the async and sync version should differ greatly. For
125 example, a MongoDB client may use the same API for async and sync
129 sync implementation should disappear when we want async version.
133 An async implementation should on compile on async implementation and
143 Handy macro to unify async and sync **unit and e2e test** code.
146 and also the conditions to compile to async test code with given test
153 # async fn async_fn() -> bool {
159 async(
163 async(
168 async fn test_async_fn() {
176 `maybe-async` compiles your code in different way with the `is_sync` feature
177 gate. It removes all `await` and `async` keywords in your code under
187 async fn async_fn_name() -> Result<(), ()> {
199 async fn async_fn_name() -> Result<(), ()> {
208 async fn maybe_async_fn() -> Result<(), ()> {
216 When `maybe-async` feature gate `is_sync` is **NOT** set, the generated code
217 is async code:
222 async fn maybe_async_fn_name() -> Result<(), ()> {
233 async fn maybe_async_fn_name() -> Result<(), ()> {
241 async fn maybe_async_fn() -> Result<(), ()> {
248 When `maybe-async` feature gate `is_sync` is set, all async keyword is
285 API of async and sync version is almost the same, such as creating or
289 actually free us from writing almost the same code for sync and async. We
290 can toggle between a sync AWZ3 client and async one by `is_sync` feature
291 gate when we add `maybe-async` to dependency.