Comment by ~tdeo on ~tdeo/serde_bare
#From seems good, but I'm not sure about Deref - see https://rust-lang.github.io/api-guidelines/predictability.html#c-deref
Tadeo
On Sun, Apr 21, 2024, at 12:10, ~chiefnoah wrote:
I'm happy to send some patches
-- View on the web: https://todo.sr.ht/~tdeo/serde_bare/6#event-346841
Comment by ~tdeo on ~tdeo/serde_bare
Hi, sorry for not replying for this long.
The
Uint
type is meant to be used like any other integer type, likeu64
. You can embed it inside a struct, and then create a value for it withUint(value)
.
Comment by ~tdeo on ~tdeo/serde_bare
Hi, I'm not sure I understand. You can just remove your
#[serde(tag = "protocol", content = "data", rename_all = "snake_case")]
and it will be serialized correctly, into a BARE tagged union.The only case where this should be a problem is when trying to use the same Serde implementations for multiple data formats, and you're using overrides to fit with an existing convention.
Comment by ~tdeo on ~tdeo/serde_bare
Hi, there are some Serde features that only make sense in the context of self-describing serialization formats like JSON, YAML, and CBOR rather than non-self-describing formats like BARE or Bincode.
In BARE, enum variant names as well as struct fields are completely ignored, so the
rename_all
in your example has no effect withserde_bare
.Serialising this enum works and results in the equivalent of the following encoding schema:
type Payload { protocol: string data: data }
This is actually not what happens, it actually becomes
{ protocol: string data: { name: optional<string> } }
when serializing
Start
and{ protocol: string data: { name: string } }
when serializing
Confirm
.While it's technically possible to deserialize such a message properly, I don't believe any BARE implementation can actually represent this as a native type.
When the derived
Deserialize
implementation goes to deserialize it,deserialize_identifier
is called.
deserialize_identifier
's documentation is:[...] the name of a struct field or the discriminant of an enum variant.
In formats like JSON, these would both be represented as strings, but in BARE, struct fields are unnecessary (since fields must always be in order), and enum discriminants are simple
uint
s.It's not possible to know in advance whether we're deserializing a
string
or auint
, soserde_bare
can't support this kind of use.If you're looking to share Serialize/Deserialize implementations between BARE and other formats, it seems it's likely not possible for cases like this. See https://github.com/bincode-org/bincode/issues/272 for a similar issue with Bincode.
Comment by ~tdeo on ~tdeo/serde_bare
Hi, I think for slices you should be able to do this using
std::io::Cursor
'sposition()
method, and usingfrom_reader
instead offrom_slice
.I'm not sure if there's a convenient wrapper for other readers, though.
Comment by ~tdeo on ~tdeo/serde_bare
I think this would be quite brittle.
- It would only work with optional types if the supplied value
- It wouldn't work on non-active enum variants.
And probably more. I think the schema to Rust code generation is a better path for this.
REPORTED
RESOLVED WONT_FIXTicket created by ~tdeo on ~tdeo/serde_bare
This could be done as a bang-style procedural macro or a function to call from your build.rs file. Not sure which to do yet.
Ticket created by ~tdeo on ~tdeo/serde_bare
Ticket created by ~tdeo on ~sircmpwn/paste.sr.ht
Private pastes can't be viewed and throw an unauthorized error, but it does link to unlisted pastes.