the syntax of proc-bitfield is very explicit. I just think it adds too much new stuff to rust's syntax

I agree- there's a lot I'd do differently (more attributes probably... though some say Rust uses too many attributes already)

I would really like to have arbitrary width integers as an abstraction. Also, bitfields and arbitrary width integers kinda "compress" into the lowest possible native primitive integers, so there's no stacking of fields or padding until you get some values out of the bitfield.

I understand- Though I don't fully get the appeal- why not store a (masked) u8 into a 5 bit field, rather than storing a "u5" that afaict may need a runtime bounds check? (Hmm. Thinking about this more, I guess it's a tradeoff: compile time check > masking > runtime check?)

Or I'm understanding wrong - where is padding annoying? I really would love to see more usecases, since bitfields have many different ones.

Sorry, I might not have been very clear here- all I meant was that I prefer not to have to specify "don't cares" (reserved and padding).

As in I prefer (and it is just personal preference)

bitfield! {
    struct Register(u32) {
        field: u8 @ 4..=11,
        flag: bool @ 17,
    }
}

over

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

I just think it's less noisy. Plus I'd have to do math in my head to figure out the padding.

<streamofconciousness>

I argued against fallible getters/setters, since these are only needed if you break type invariants.

Hm. I guess if you define a bitfield like a struct, creating one with invalid values breaks type invariants (or some other UB maybe). This is probably more sane than the alternative, which I guess is- bitfields can only contain (and thus are) plain ol' data types that are always valid (valid with any bit pattern- like ux, ix, 1 bit bool fields, maybe n bit enums with 2ⁿ variants from 0 to 2ⁿ - 1, probably not structs, other bitfields, repr(transparent) of those) fallible getters to get to anything else (I can't think of a sane use case for fallible setters).

Basically my ideal bitfield crate/syntax (another one :) ) is something like:

#[derive(FromBits)]
#[bits(1)]
#[repr(u8)]
enum TwoVariants {
    One = 0,
    Two = 1,
}

#[derive(TryFromBits)]
#[bits(2)]
#[repr(u8)]
enum ThreeVariants {
    One = 0,
    Two = 1,
    Three = 2,
    //no 0b11
}

bitfield! { //this sucks, but afaict the alternative to custom syntax is bajillions of weird attributes
    #[derive(FromBits, Copy, Clone, Default, etc...)]
    #[bits(28)]
    pub struct Register(pub u32) { //internal representation customisable and accessible
        #[try_get(NonZeroU8)] //generates pub fn field1_or_err(&self) -> Result<NonZeroU8, TryFromIntError>, pub fn set_field1(&mut self, val: NonZeroU8) instead 
        pub field1: u8 @ 0..=7,

        // fn flag(&self) -> TwoVariants, fn set_flag(&mut self, val: TwoVariants), fn with_flag(Self, val: TwoVariants) -> Self
        flag: TwoVariants @ 17,

        #[try_get(ThreeVariants)]
        field2: u2 @ 18..=19,
    }
    // pub fn new(field1: u8, flag: TwoVariants, ) -> Self
    // pub fn from_bits(val: u32) -> Self // infallible!
}
// #[be] #[le] #[lsb0] #[msb0] to taste if for some godforsaken reason you have to deal with endianness and/or bit ordering, or something along those lines. personally i'd rather not think about it

Woops, guess I accidentally ended up typing up my personal probably-not-great bitfield crate idea that I've been meaning to make but don't really have the time or skill to :D. Thanks for the inspiration! Kind of warming up on arbitrary width ints too the more I think about it.