[ohr]

That's understandable, but I think it depends on how many different structs like this you have and how many fields you need to work with (for our usecase, we had tens of structs with tens of fields each).

There's also an Alternatives section in the article about other approaches that can achieve similar results, but of course 'do nothing' is also a valid option.

Edit: > If actually concerned about the need to know UI8 ..

Just a small note: even if you don't care about the fact that it's a UI8, you still have to use the correct type. For example, if the field happens to be returned as UI4, this code won't work!

[dundarious]

Right, but isn't the struct definition equivalent in line count and effort compared to some typedefs and perhaps a handful of trivial-to-inspect oneline helper functions?

Regarding the UI8, don't you have to get your version's struct data member type correct to the exact same degree as a typedef in my suggestion?

[ohr]

> don't you have to get your version's struct data member type correct

No, since Serde will happyly fill a `u64` field with any other `u{8,16,32}` value, and even with signed types (as long as the actual value is non-negative) - this is sort of what happens when you deserialize a JSON `[1, 2, 3]` into `[u64]`.

[dundarious]

Yes, but an equivalent to `impl<'de> Deserializer<'de> for ValueDeserializer` handles that. That could be a useful helper.