Warning

This post was published 123 days ago. The information described in this article may have changed.

Info

This post is auto-generated from RSS feed The Rust Programming Language Forum - Latest topics. Source: Future-proofing message serialization

Following up on How do I future proof (de)serialization of types that might change across versions? - #2 by Schard , the accepted answer is to use versioned enums like

#[derive(Serialize, Deserialize)]
enum MyThing {
  V1(pub MyThingV1),
  V2(pub MyThingV2),
  ...
}

While I am in love with this approach, enum discriminants aren’t stable if you change the definition or the Rust compiler. Reading the language section Enumerations - The Rust Reference , I’m led to believe that if the following does explicitly constrain the discriminant so we don’t have this issue as long as I only ever append to the enum list:

#[repr(u32)]
#[derive(Serialize, Deserialize)]
enum MyThing {
  First = 0
  V1(pub MyThingV1),
  V2(pub MyThingV2),
  ...
}

I suppose there’s also a second possibility that serde doesn’t case about discriminants and assigns its own for enum variants for serialization purposes.

3 posts - 3 participants

Read full topic

🏷️ Rust_feed