3 ms·

Yes, I can use numbers to represent anything, but I will lost compiler support. It's not a solution but workaround. I saw number of tickets about that in Rust

• Twisol 8y ago
  For the first one, which I see you've made a comment on: > This behaviour affects Prost: i32 type is used instead of enum type, because Protobuf defines that enum variable must be able to hold values outside of enum range to be compatible with future versions. As alternative solution, it's proposed to use _Unknonwn_(i32) variant, but this solution cannot be implemented in current version of Rust, because C-like enums cannot contain tags. In principle, a protobufs library (like Prost) could map a protobuf enum `X` into a Rust enum `ProtobufEnum<X>` with `Known(X)` and `Unknown(i32)` fields. Or autogenerate a Rust enum with the known variants inlined, plus the extra Unknown field. It is incumbent on the library author and/or FFI user to map semantic notions appropriately across the interface. Rust enums do not have C semantics, even if the underlying machine representation is annotated to mimic C. If something across the interface allows its flavor of enum to take on unnamed values, then that semantics needs to be preserved faithfully in Rust -- and that may mean using something slightly different from what Rust itself natively provides.
  • v_lisivka 8y ago
    > Or autogenerate a Rust enum with the known variants inlined, plus the extra Unknown field. Unfortunately, support for this extra Unknown() field is not added to rustc yet even in Rust2018 edition. Compiler can do that, because it already used to save space for Option<>. > Rust enums do not have C semantics, even if the underlying machine representation is annotated to mimic C. Yes, it's the bug I'm talking about. Solutions are: a) remove repr(C), b) fix repr(C).