Closed bryanjswift closed 4 years ago
Simply removing the implementation for #[cfg(not(target_arch = "wasm32"))]
might be better. It would certainly make it more obvious to consumers of the crate that the feature was only available for wasm32 and would maybe prevent surprising runtime behavior 🤔
I support removing it, but there's a catch: we need it for the docs, which is compiled w/ target_arch = "x86_64", or similar depending on the machine running it. Maybe we can mark it with #[deprecated]
and then panic inside the impl?
I support removing it, but there's a catch: we need it for the docs, which is compiled w/ target_arch = "x86_64", or similar depending on the machine running it. Maybe we can mark it with
#[deprecated]
and then panic inside the impl?
I had originally had the contents as unimplemented!("
Transmitter::send_asyncis only implemented for wasm32")
which does panic. I didn't like the feel of having an intentional runtime panic in the published API though (I suppose a runtime do nothing is arguably worse though so... there's that). Is it possible to compile docs with a different target_arch?
#[cfg(doc)]
appears to work for allowing cargo doc
to run, cargo test
fails to find it with #[cfg(test)]
though. Trying some other options.
The
futures::executor::block_on
didn't work inside atokio
runtime which will be too common a scenario to ignore. Outside of implementing a customWaker
to loop and poll theFuture
to completion spawning a "local" context similar to the wasm32 behavior is more difficult than anticipated. Without the use offutures
inTransmitter::send_async
it is safe to removefutures
from the dependencies of mogwai.Refs #52 Closes #57