Finn Bear

> if there are plans to add support for rust-decimal The process for supporting library X is: 1. if the library doesn't have a precedent for supporting niche encoding crates,...

Thanks for the PR! Here are a few thoughts: - I'm in favor of accepting this `impl` if `uuid` doesn't want to derive it :+1: - The binary representation you...

Thanks for this! Regarding the encoding process, @caibear has recently started experimenting with using `uuid`'s support for `bytemuck` to make it more efficient than what I suggested. I'll keep you...

Good to know multiple people want it. This increases the priority.

Thanks for the issue! Our motivation to support this, like other crates, depends on how much demand there is. For now, you can use the `serde` version of `bitcode`.

Thanks for the PR! I'm curious why you didn't use the `ConvertFrom` approach to reduce code duplication. > I am not sure why but this line throw an error: assert!(crate::decode::(&crate::encode(&(23,...

Thanks! As far as I'm personally concerned, there is no need to wait for implementing all types of a crate before merging any given PR. This PR looks good to...

Thanks for the issue! Our motivation to support this, like other crates, will depend on how much demand there is. For now, you can use the `serde` version of `bitcode`.

Have you considered this? ```rust let handle = axum_server::Handle::default(); let handle_clone = handle.clone(); tokio::spawn(async move { // TODO: what you would have put in `with_graceful_shutdown` handle_clone.graceful_shutdown(Some(Duration::from_secs(1))); }); axum_server::bind(...) .handle(handle) .serve(...)...

> Might be relevant for [#211 (comment)](https://github.com/BiagioFesta/wtransport/pull/211#discussion_r1742406771) Can confirm; you [use the conversion for application error/close codes](https://github.com/MOZGIII/xwt/blob/ffc8b2cc135acaf7f5229a01775e3da92a22684e/crates/xwt-wtransport/src/lib.rs#L166-L167), which is correct. This conversion could be moved into `wtransport`.