alloc crate is often used in crates that are almost
no_std-compatible and only need allocation capabilities to do their thing.
The problem one usually faces when developing one of these "maybe std, maybe
alloc" crates is that for the
std variant, everything is available either
in the prelude or at
std:: paths, while in
alloc-only situations, the
prelude must be imported manually and everything lives under
To work around this, one could simply have
#[cfg(...)] conditionals over
all of the imports as needed, but this quickly gets ugly and unwieldy. A
better approach is to use a facade which re-exports the api from either
alloc, whichever happens to be in use at the time.
This crate provides such a facade. Simply make sure that one of either its
alloc features is enabled and it provides the same importable API
structure for either case. Optionally, the
futures feature can also be
enabled to provide the
Rather than use this facade crate directly, one could also use the
setup_imports macro which will generate a similar facade in your own crate.
This is useful if the conditions for enabling
alloc are more
complicated than a simple feature flag. See its documentation for more details.