tokio-rs
128 bit
What do we think of natively supporting u128 / i128 by applying https://github.com/protocolbuffers/protobuf/blob/20a30c675a4fa51736dd183ff9ecf16ef8300325/src/google/protobuf/stubs/int128.h
u128 quite a common datatype nowadays => ipv6, uuid, sol/eth/bitc, etc...
also - well aware it's not standard to require "external types" outside the core protobuf language
however, we have the elegance of cargo for additional features :)
...would propose an opt-in compiler flag in .toml
Anything can be provided by an external crate. And complicate the software chain of protobuf generation.
Rather, I think the narrative should follow:
Why do people use the Prost crate?
It decodes protobuf byte streams onto Rust primitives - rather than ffi <> gprc-c/grpc-c++ api
What's the benefit of Prost over alternative implementations?
Centralize definitions into protobufs, rather than decoding from a library model into native rust model then encoding back to library model
Why include this feature?
u128 happens to be a rust primitive - which falls inline w/ the boundary & advantage of this library
accordingly, though that may be a valid answer for alternative, random data types, I think this should be included natively.
Yeah that seems fair, I guess since rust supports it as a primitive we could add support. I would be open to accepting a PR for this.
Hi, I'd like to make this real. We highly need this. But I'm not sure how to achieve it. It'd be nice if someone can give me some guidance on this feature.
hi @thaodt you can come on discord and we can chat in the #prost channel (the tokio.rs discord). I believe this change will just require implementing Message for these types similar to what we do for u64 etc https://docs.rs/prost/latest/prost/trait.Message.html#impl-Message-for-u64
Closing this - until hardware supports u128 (40 yrs), individuals should opt for string type <> u128. Proprietary protocols can implement custom bytes approach as linked above.