Serde varint type

[green fjord]

I've done a little bit of research, and I've come to the conclusion that a lot of libraries that implement variable integers use deserialize_with, like, #[serde(deserialize_with="varint_decode")]. I'm interested in having a newtype, like, pub struct VarInt(i32); to represent them, instead of having to declare the field attribute each time, as they're common in the protocol I'm working with. I thought about implementing Deserialize for VarInt, but I'm sort of confused about it, since the Deserializer should do the actual decoding. Any advice?

[lilac ether]

What is variable integer? You mean fixed precision numbers?

[green fjord]

No, I mean unfixed numbers. Like zigzag

[vital bronze]

Does your protocol support both variable- and fixed-width encoding?

[green fjord]

Yes, which does add to the issue. I would've just decoded all integers as varints otherwise :p

[vital bronze]

Right. You have to do horrible hacks in that case

Because you’re goïng outside the Serde data model

(this is why Serde is actually not very good at most things)

Basically, detect when the user calls deserialize_unit_struct("37ඞඞ__YOURFORMAT_HACK_VARINT_DO_NOT_USE__ඞඞ", v) in your Deserializer

and then if they call that, give them the varint

[green fjord]

Ah, so, just deserialize different if it's a struct of the name VarInt or VarLong?

Actually, I suppose I could do deserialize_newtype_struct with the same technique?

[vital bronze]

It doesnt matter which method you hack into, yeah

[vital bronze]

It has to be a name the user wouldn’t possibly think of using

otherwise you get collisions

Hence why I suggest 37ඞඞ__YOURFORMAT_HACK_VARINT_DO_NOT_USE__ඞඞ

It starts with a number so can’t be a struct name, and has uncommon characters, etc

but it doesn’t matter it’ll just a const buried somewhere in your code

[green fjord]

This is hurting me tbh.