Open hecatia-elegua opened 1 year ago
To be clear, would this allow FromBits
? How would this interact with non-zero patterns for padding? For example,
#[bitsize(4)]
#[derive(FromBits)]
struct Tiny {
#[at(2)]
field: u2
}
what would you get for Tiny::from(u4::new(0b1111))
?
In my head it would basically expand to
struct Tiny {
reserved_i: u2,
field: u2
}
+1 to this idea. Additionally:
bitbybit
: it can have integers spread across multiple non-contiguous ranges: https://github.com/danlehmann/bitfield?tab=readme-ov-file#non-contiguous-bitranges -- and I am currently looking at serializing a couple structs that do have non-contiguous bit ranges (I'm working with a 1990s tape format where they let no bit go to waste anywhere...). So it would be a nice touch if that could be done.unsafe
to access...?In general, I like the way it could potentially show and enforce the offsets that can easily be compared with a datasheet or other external specification showing the bit field we are modeling. Whereas if no offsets are set, then I have to do math to figure out if everything is correct, or go through the list and hope I figured out the size of each thing correctly, etc.
It's all maybe a little nit-picky for most people, but seems like would be a nice touch.
So that
is the same as
or
Here, we use a similar logic to enum discriminant counting: The first field starts at 0, unless a range is given. The next field starts at the end of the previous field's range, unless a range is given.
This could be expanded, again similar to enums, to allow reordering.