Padding options

[osiler]

Hi,

Thanks for the work on this crate its been very helpful. I was wondering if you thought it would be worth adding an option for the padding to specify pad with 0, or with 1. A coms protocol I am currently looking at pads with ones in some sections, I've generally got around this by specifying some extra enum type with a default value and implementing the From<> traits to make it work. Potentially a match on _0* and _1* which would not break the current implementation.

[wrenger]

Hi @osiler,
That's a good idea. I generally want to have a way to specify defaults that are automatically set by new().
Something like the following:

#[bitfield(u8)]
struct MyByte {
    #[bits(4, default = 0b1100)]
    kind: usize,
    #[bits(1, default = true)]
    system: bool,
    #[bits(3, default = 0b111)]
    _p: ()
}

let my_byte = MyByte::new();
assert!(my_byte.system());

This would also cover your use case, if I'm correct?

[osiler]

Yes that would be great, having the default derive will also be helpful. How would the bit-field default work with a custom type? Ill have to double check but previously when I set a default on a custom enum type it was not passed through to the owned bit-field struct.

[wrenger]

Custom types are difficult because of const (compile-time evaluation). I want to have the new function as const fn to use bitfields in static variables etc. However, const traits (rust-lang/rust#67792) are not stable yet. This prevents us from using Default or From in the new() function and is the reason that the <name> and with_<name> accessor functions are not const for custom types.

I might have to redesign custom types in general, maybe without using traits at all and specific functions instead.

#[bitfield(u8)]
struct MyByte {
    #[bits(4, default = 0b1100)]
    kind: usize,
    #[bits(1, default = true)]
    system: bool,
    #[bits(3, default = MyEnum::A, to = MyEnum::to_bits, from = MyEnum::from_bits)]
    custom: MyEnum
}

#[repr(u8)]
struct MyEnum {
    A, B, C
}

impl MyEnum {
    const fn to_bits(self) -> u8 {
        self as u8
    }
    const fn from_bits(v: u8) -> Self {
        match v {
            0 => Self::A,
            1 => Self::B,
            _ => Self::C,
        }
    }
}

In general, I'm currently unsure what the best direction would be considering #7...

[wrenger]

I've implemented the concept on #16. What do you think @osiler?

[osiler]

Hi @wrenger

Thanks for the implementation. Its definitely a downside that the const fns cannot be wrapped in a trait, I guess this will make it hard to catch implementation issues when people are having trouble with their custom types not implementing the correct "from_bits" and "to_bits" function. I'm unsure how you could catch this without having the trait bounds that const fns in traits would provide other than trying to pattern match the impl of the custom type. I definitely got used to implementing From fo Y while using the crate.

Ultimately I do like the above API, I am just unsure how the backwards compatibility will go when const fns do land in traits and many have implemented there own named fns.

[wrenger]

Yes if const traits are becoming stable (in whatever form), we probably should revert back to From/Into. Nonetheless, the custom from_bits/into_bits functions will still work regardless.

Also the Macro can currently be configured to use these traits (on nightly) with #[bits(MyType, from = From::from, into = Into::into)].

[wrenger]

Released in version 0.5