1 unstable release
0.3.0 | Aug 19, 2024 |
---|
#935 in Encoding
30 downloads per month
16KB
271 lines
Prost convert
FAQ
Why not use the standard From
and TryFrom
trait?
We redefine our own conversion trait which might not seem logical.
The main reason is to support removing unwanted optional field
In rust we have
impl<T> From<T> for Option<T> { /**/}
which allows
let o: Option<u8> = Option::from(67);
assert_eq!(Some(67), o);
But if we have
struct U;
impl From<U> for T { /**/}
we don't have
impl<T, U> From<U> for Option<T>
where
T: From<U>,
{
fn from(value: U) -> Self {
Some(value.into())
}
}
We can't add this impl due to the orphan rule, so we add our own conversion trait. It’s mostly transparent to the user because most of the time it will be impl through a derive macro.
TODO
- impl for NonZero types from the std.
- Explore the possibility to use an associated type for the error.
- impl for
Bytes
https://docs.rs/prost/latest/prost/trait.Message.html#foreign-impls - Prost support to switch from
HashMap
toBTreeMap
so we should supportBTreeMap
also. - Should we make a blanket impl for all the type in the std that impl From/TryFrom (ex u16 and u32). Useful when we have a native type (u16) that can’t be express in the proto. If we don't control the proto and and they define a uint64 and we want a u16 we could provide conversion too.
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
Dependencies
~0.6–1MB
~23K SLoC