Optionally support specifying the bit-range of a field instead

[hecatia-elegua]

So that

#[bitsize(32)]
struct Register {
    padding: u4,
    field: u8,
    flag1: bool,
    padding: u4,
    flag2: bool,
    padding: u14,
}

is the same as

#[bitsize(32)]
struct Register {
    #[at(4..=11)]
    field: u8,
    flag1: bool,
    #[at(17)]
    flag2: bool,
}

or

#[bitsize(32)]
struct Register {
    #[at(4)]
    field: u8,
    flag1: bool,
    #[at(17)]
    flag2: bool,
}

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.

[pickx]

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))?

[hecatia-elegua]

In my head it would basically expand to

struct Tiny {
    reserved_i: u2,
    field: u2
}

[JohnstonJ]

+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.
• With the specification of offsets, it is easy for there to be miscalculations. The user may want to configure some of these options via attribute:
  • Whether or not to auto-insert reserved fields, such as the example you gave: Optionally support specifying the bit-range of a field instead #28 (comment) .... if not, then there should be a compile error
  • Whether to allow overlapping bit ranges. Maybe some users want it to act like a C union. Maybe others would consider this to be a mistake and want a compile error. Seems to me that if you want overlapping bits, it ought to be explicitly defined, and maybe considered 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.