android/vendor/maybe-async-0.2.7/README.md - toolchain/cargo-deny - Git at Google

 # Maybe-Async Procedure Macro

 **Why bother writing similar code twice for blocking and async code?**

 [![Build Status](https://github.com/fMeow/maybe-async-rs/workflows/CI%20%28Linux%29/badge.svg?branch=main)](https://github.com/fMeow/maybe-async-rs/actions)
 [![MIT licensed](https://img.shields.io/badge/license-MIT-blue.svg)](./LICENSE)
 [![Latest Version](https://img.shields.io/crates/v/maybe-async.svg)](https://crates.io/crates/maybe-async)
 [![maybe-async](https://docs.rs/maybe-async/badge.svg)](https://docs.rs/maybe-async)

 When implementing both sync and async versions of API in a crate, most API
 of the two version are almost the same except for some async/await keyword.

 `maybe-async` help unifying async and sync implementation by **procedural
 macro**.
 - Write async code with normal `async`, `await`, and let `maybe_async`
   handles
 those `async` and `await` when you need a blocking code.
 - Switch between sync and async by toggling `is_sync` feature gate in
   `Cargo.toml`.
 - use `must_be_async` and `must_be_sync` to keep code in specified version
 - use `impl_async` and `impl_sync` to only compile code block on specified
   version
 - A handy macro to unify unit test code is also provided.

 These procedural macros can be applied to the following codes:
 - trait item declaration
 - trait implmentation
 - function definition
 - struct definition

 **RECOMMENDATION**: Enable **resolver ver2** in your crate, which is
 introduced in Rust 1.51. If not, two crates in dependency with conflict
 version (one async and another blocking) can fail complilation.


 ## Motivation

 The async/await language feature alters the async world of rust.
 Comparing with the map/and_then style, now the async code really resembles
 sync version code.

 In many crates, the async and sync version of crates shares the same API,
 but the minor difference that all async code must be awaited prevent the
 unification of async and sync code. In other words, we are forced to write
 an async and an sync implementation repectively.

 ## Macros in Detail

 `maybe-async` offers 4 set of attribute macros: `maybe_async`,
 `sync_impl`/`async_impl`, `must_be_sync`/`must_be_async`,  and `test`.

 To use `maybe-async`, we must know which block of codes is only used on
 blocking implementation, and which on async. These two implementation should
 share the same function signatures except for async/await keywords, and use
 `sync_impl` and `async_impl` to mark these implementation.

 Use `maybe_async` macro on codes that share the same API on both async and
 blocking code except for async/await keywords. And use feature gate
 `is_sync` in `Cargo.toml` to toggle between async and blocking code.

 - `maybe_async`

     Offers a unified feature gate to provide sync and async conversion on
     demand by feature gate `is_sync`, with **async first** policy.

     Want to keep async code? add `maybe_async` in dependencies with default
     features, which means `maybe_async` is the same as `must_be_async`:

     ```toml
     [dependencies]
     maybe_async = "0.2"
     ```

     Wanna convert async code to sync? Add `maybe_async` to dependencies with
     an `is_sync` feature gate. In this way, `maybe_async` is the same as
     `must_be_sync`:

     ```toml
     [dependencies]
     maybe_async = { version = "0.2", features = ["is_sync"] }
     ```

     Not all async traits need futures that are `dyn Future + Send`.
     To avoid having "Send" and "Sync" bounds placed on the async trait
     methods, invoke the maybe_async macro as #[maybe_async(?Send)] on both
     the trait and the impl blocks.


 - `must_be_async`

     **Keep async**. Add `async_trait` attribute macro for trait declaration
     or implementation to bring async fn support in traits.

     To avoid having "Send" and "Sync" bounds placed on the async trait
     methods, invoke the maybe_async macro as #[must_be_async(?Send)].

 - `must_be_sync`

     **Convert to sync code**. Convert the async code into sync code by
     removing all `async move`, `async` and `await` keyword


 - `sync_impl`

     An sync implementation should on compile on blocking implementation and
 must     simply disappear when we want async version.

     Although most of the API are almost the same, there definitely come to a
     point when the async and sync version should differ greatly. For
     example, a MongoDB client may use the same API for async and sync
     verison, but the code to actually send reqeust are quite different.

     Here, we can use `sync_impl` to mark a synchronous implementation, and a
     sync implementation shoule disappear when we want async version.

 - `async_impl`

     An async implementation should on compile on async implementation and
 must     simply disappear when we want sync version.

     To avoid having "Send" and "Sync" bounds placed on the async trait
     methods, invoke the maybe_async macro as #[async_impl(?Send)].


 - `test`

     Handy macro to unify async and sync **unit and e2e test** code.

     You can specify the condition to compile to sync test code
     and also the conditions to compile to async test code with given test
     macro, e.x. `tokio::test`, `async_std::test` and etc. When only sync
     condition is specified,the test code only compiles when sync condition
     is met.

     ```rust
     #[maybe_async::test(
         feature="is_sync",
         async(all(not(feature="is_sync"), feature="async_std"), async_std::test),
         async(all(not(feature="is_sync"), feature="tokio"), tokio::test)
     )]
     async fn test_async_fn() {
         let res = async_fn().await;
         assert_eq!(res, true);
     }
     ```

 ## What's Under the Hook

 `maybe-async` compiles your code in different way with the `is_sync` feature
 gate. It remove all `await` and `async` keywords in your code under
 `maybe_async` macro and conditionally compiles codes under `async_impl` and
 `sync_impl`.

 Here is an detailed example on what's going on whe the `is_sync` feature
 gate set or not.

 ```rust
 #[maybe_async::maybe_async(?Send)]
 trait A {
     async fn async_fn_name() -> Result<(), ()> {
         Ok(())
     }
     fn sync_fn_name() -> Result<(), ()> {
         Ok(())
     }
 }

 struct Foo;

 #[maybe_async::maybe_async(?Send)]
 impl A for Foo {
     async fn async_fn_name() -> Result<(), ()> {
         Ok(())
     }
     fn sync_fn_name() -> Result<(), ()> {
         Ok(())
     }
 }

 #[maybe_async::maybe_async]
 async fn maybe_async_fn() -> Result<(), ()> {
     let a = Foo::async_fn_name().await?;

     let b = Foo::sync_fn_name()?;
     Ok(())
 }
 ```

 When `maybe-async` feature gate `is_sync` is **NOT** set, the generated code
 is async code:

 ```rust
 // Compiled code when `is_sync` is toggled off.
 #[async_trait::async_trait(?Send)]
 trait A {
     async fn maybe_async_fn_name() -> Result<(), ()> {
         Ok(())
     }
     fn sync_fn_name() -> Result<(), ()> {
         Ok(())
     }
 }

 struct Foo;

 #[async_trait::async_trait(?Send)]
 impl A for Foo {
     async fn maybe_async_fn_name() -> Result<(), ()> {
         Ok(())
     }
     fn sync_fn_name() -> Result<(), ()> {
         Ok(())
     }
 }

 async fn maybe_async_fn() -> Result<(), ()> {
     let a = Foo::maybe_async_fn_name().await?;
     let b = Foo::sync_fn_name()?;
     Ok(())
 }
 ```

 When `maybe-async` feature gate `is_sync` is set, all async keyword is
 ignored and yields a sync version code:

 ```rust
 // Compiled code when `is_sync` is toggled on.
 trait A {
     fn maybe_async_fn_name() -> Result<(), ()> {
         Ok(())
     }
     fn sync_fn_name() -> Result<(), ()> {
         Ok(())
     }
 }

 struct Foo;

 impl A for Foo {
     fn maybe_async_fn_name() -> Result<(), ()> {
         Ok(())
     }
     fn sync_fn_name() -> Result<(), ()> {
         Ok(())
     }
 }

 fn maybe_async_fn() -> Result<(), ()> {
     let a = Foo::maybe_async_fn_name()?;
     let b = Foo::sync_fn_name()?;
     Ok(())
 }
 ```

 ## Examples

 ### rust client for services

 When implementing rust client for any services, like awz3. The higher level
 API of async and sync version is almost the same, such as creating or
 deleting a bucket, retrieving an object and etc.

 The example `service_client` is a proof of concept that `maybe_async` can
 actually free us from writing almost the same code for sync and async. We
 can toggle between a sync AWZ3 client and async one by `is_sync` feature
 gate when we add `maybe-async` to dependency.


 # License
 MIT
	# Maybe-Async Procedure Macro

	Why bother writing similar code twice for blocking and async code?

	[![Build Status](https://github.com/fMeow/maybe-async-rs/workflows/CI%20%28Linux%29/badge.svg?branch=main)](https://github.com/fMeow/maybe-async-rs/actions)
	[![MIT licensed](https://img.shields.io/badge/license-MIT-blue.svg)](./LICENSE)
	[![Latest Version](https://img.shields.io/crates/v/maybe-async.svg)](https://crates.io/crates/maybe-async)
	[![maybe-async](https://docs.rs/maybe-async/badge.svg)](https://docs.rs/maybe-async)

	When implementing both sync and async versions of API in a crate, most API
	of the two version are almost the same except for some async/await keyword.

	`maybe-async` help unifying async and sync implementation by **procedural
	macro**.
	- Write async code with normal `async`, `await`, and let `maybe_async`
	handles
	those `async` and `await` when you need a blocking code.
	- Switch between sync and async by toggling `is_sync` feature gate in
	`Cargo.toml`.
	- use `must_be_async` and `must_be_sync` to keep code in specified version
	- use `impl_async` and `impl_sync` to only compile code block on specified
	version
	- A handy macro to unify unit test code is also provided.

	These procedural macros can be applied to the following codes:
	- trait item declaration
	- trait implmentation
	- function definition
	- struct definition

	RECOMMENDATION: Enable resolver ver2 in your crate, which is
	introduced in Rust 1.51. If not, two crates in dependency with conflict
	version (one async and another blocking) can fail complilation.


	## Motivation

	The async/await language feature alters the async world of rust.
	Comparing with the map/and_then style, now the async code really resembles
	sync version code.

	In many crates, the async and sync version of crates shares the same API,
	but the minor difference that all async code must be awaited prevent the
	unification of async and sync code. In other words, we are forced to write
	an async and an sync implementation repectively.

	## Macros in Detail

	`maybe-async` offers 4 set of attribute macros: `maybe_async`,
	`sync_impl`/`async_impl`, `must_be_sync`/`must_be_async`, and `test`.

	To use `maybe-async`, we must know which block of codes is only used on
	blocking implementation, and which on async. These two implementation should
	share the same function signatures except for async/await keywords, and use
	`sync_impl` and `async_impl` to mark these implementation.

	Use `maybe_async` macro on codes that share the same API on both async and
	blocking code except for async/await keywords. And use feature gate
	`is_sync` in `Cargo.toml` to toggle between async and blocking code.

	- `maybe_async`

	Offers a unified feature gate to provide sync and async conversion on
	demand by feature gate `is_sync`, with async first policy.

	Want to keep async code? add `maybe_async` in dependencies with default
	features, which means `maybe_async` is the same as `must_be_async`:

	```toml
	[dependencies]
	maybe_async = "0.2"
	```

	Wanna convert async code to sync? Add `maybe_async` to dependencies with
	an `is_sync` feature gate. In this way, `maybe_async` is the same as
	`must_be_sync`:

	```toml
	[dependencies]
	maybe_async = { version = "0.2", features = ["is_sync"] }
	```

	Not all async traits need futures that are `dyn Future + Send`.
	To avoid having "Send" and "Sync" bounds placed on the async trait
	methods, invoke the maybe_async macro as #[maybe_async(?Send)] on both
	the trait and the impl blocks.


	- `must_be_async`

	Keep async. Add `async_trait` attribute macro for trait declaration
	or implementation to bring async fn support in traits.

	To avoid having "Send" and "Sync" bounds placed on the async trait
	methods, invoke the maybe_async macro as #[must_be_async(?Send)].

	- `must_be_sync`

	Convert to sync code. Convert the async code into sync code by
	removing all `async move`, `async` and `await` keyword


	- `sync_impl`

	An sync implementation should on compile on blocking implementation and
	must simply disappear when we want async version.

	Although most of the API are almost the same, there definitely come to a
	point when the async and sync version should differ greatly. For
	example, a MongoDB client may use the same API for async and sync
	verison, but the code to actually send reqeust are quite different.

	Here, we can use `sync_impl` to mark a synchronous implementation, and a
	sync implementation shoule disappear when we want async version.

	- `async_impl`

	An async implementation should on compile on async implementation and
	must simply disappear when we want sync version.

	To avoid having "Send" and "Sync" bounds placed on the async trait
	methods, invoke the maybe_async macro as #[async_impl(?Send)].


	- `test`

	Handy macro to unify async and sync unit and e2e test code.

	You can specify the condition to compile to sync test code
	and also the conditions to compile to async test code with given test
	macro, e.x. `tokio::test`, `async_std::test` and etc. When only sync
	condition is specified,the test code only compiles when sync condition
	is met.

	```rust
	#[maybe_async::test(
	feature="is_sync",
	async(all(not(feature="is_sync"), feature="async_std"), async_std::test),
	async(all(not(feature="is_sync"), feature="tokio"), tokio::test)
	)]
	async fn test_async_fn() {
	let res = async_fn().await;
	assert_eq!(res, true);
	}
	```

	## What's Under the Hook

	`maybe-async` compiles your code in different way with the `is_sync` feature
	gate. It remove all `await` and `async` keywords in your code under
	`maybe_async` macro and conditionally compiles codes under `async_impl` and
	`sync_impl`.

	Here is an detailed example on what's going on whe the `is_sync` feature
	gate set or not.

	```rust
	#[maybe_async::maybe_async(?Send)]
	trait A {
	async fn async_fn_name() -> Result<(), ()> {
	Ok(())
	}
	fn sync_fn_name() -> Result<(), ()> {
	Ok(())
	}
	}

	struct Foo;

	#[maybe_async::maybe_async(?Send)]
	impl A for Foo {
	async fn async_fn_name() -> Result<(), ()> {
	Ok(())
	}
	fn sync_fn_name() -> Result<(), ()> {
	Ok(())
	}
	}

	#[maybe_async::maybe_async]
	async fn maybe_async_fn() -> Result<(), ()> {
	let a = Foo::async_fn_name().await?;

	let b = Foo::sync_fn_name()?;
	Ok(())
	}
	```

	When `maybe-async` feature gate `is_sync` is NOT set, the generated code
	is async code:

	```rust
	// Compiled code when `is_sync` is toggled off.
	#[async_trait::async_trait(?Send)]
	trait A {
	async fn maybe_async_fn_name() -> Result<(), ()> {
	Ok(())
	}
	fn sync_fn_name() -> Result<(), ()> {
	Ok(())
	}
	}

	struct Foo;

	#[async_trait::async_trait(?Send)]
	impl A for Foo {
	async fn maybe_async_fn_name() -> Result<(), ()> {
	Ok(())
	}
	fn sync_fn_name() -> Result<(), ()> {
	Ok(())
	}
	}

	async fn maybe_async_fn() -> Result<(), ()> {
	let a = Foo::maybe_async_fn_name().await?;
	let b = Foo::sync_fn_name()?;
	Ok(())
	}
	```

	When `maybe-async` feature gate `is_sync` is set, all async keyword is
	ignored and yields a sync version code:

	```rust
	// Compiled code when `is_sync` is toggled on.
	trait A {
	fn maybe_async_fn_name() -> Result<(), ()> {
	Ok(())
	}
	fn sync_fn_name() -> Result<(), ()> {
	Ok(())
	}
	}

	struct Foo;

	impl A for Foo {
	fn maybe_async_fn_name() -> Result<(), ()> {
	Ok(())
	}
	fn sync_fn_name() -> Result<(), ()> {
	Ok(())
	}
	}

	fn maybe_async_fn() -> Result<(), ()> {
	let a = Foo::maybe_async_fn_name()?;
	let b = Foo::sync_fn_name()?;
	Ok(())
	}
	```

	## Examples

	### rust client for services

	When implementing rust client for any services, like awz3. The higher level
	API of async and sync version is almost the same, such as creating or
	deleting a bucket, retrieving an object and etc.

	The example `service_client` is a proof of concept that `maybe_async` can
	actually free us from writing almost the same code for sync and async. We
	can toggle between a sync AWZ3 client and async one by `is_sync` feature
	gate when we add `maybe-async` to dependency.


	# License
	MIT