I've run into an interesting corner case in the bincode specification:
Option<T> is implemented as an enum
The specification says that in fixint encoding, enum discriminants are always encoded as a u32 (source)
However, a simple test program shows that an Option<T> is serialized with a 1-byte tag (instead of a u32)
fn main() {
let i: Option<u32> = Some(100);
let out = bincode::serialize(&i).unwrap();
println!("{out:?}");
let i: Option<u32> = None;
let out = bincode::serialize(&i).unwrap();
println!("{out:?}");
let i: Result<u32, u32> = Ok(101);
let out = bincode::serialize(&i).unwrap();
println!("{out:?}");
let i: Result<u32, u32> = Err(102);
let out = bincode::serialize(&i).unwrap();
println!("{out:?}");
}
Note that the Result<T, E> uses a 4-byte tag, as we'd expect from the specification.
I don't think the behavior should change at this point, but it would be good to reflect this corner case in the specification. If that makes sense, I'd be happy to submit a PR to that effect.
I've run into an interesting corner case in the
bincode
specification:Option<T>
is implemented as anenum
fixint
encoding,enum
discriminants are always encoded as au32
(source)Option<T>
is serialized with a 1-byte tag (instead of au32
)Note that the
Result<T, E>
uses a 4-byte tag, as we'd expect from the specification.I don't think the behavior should change at this point, but it would be good to reflect this corner case in the specification. If that makes sense, I'd be happy to submit a PR to that effect.