On Tue, Sep 16, 2025 at 05:59:18AM -0400, Joel Fernandes wrote: [...] > > > > The same question for the setters. What would happen for this: > > > > > > > > let bf = bf::default() > > > > .set_state(0xf) > > > > .set_ready(true); > > > > > > > > I think that after the first out-of-boundary in set_state(), you > > > > should abort the call chain, make sure you're not touching memory > > > > in set_ready() and returning some type of error. > > > > > > Here, on out of boundary, we just ignore the extra bits passed to > > > set_state. I think it would be odd if we errored out honestly. We are > > > using 'as u8' in the struct so we would accept any u8 as input, but > > > then if we complained that extra bits were sent, that would be odd. > > > > That really depends on your purpose. If your end goal is the safest API > > in the world, and you're ready to sacrifice some performance (which is > > exactly opposite to the C case), then you'd return to your user with a > > simple question: are you sure you can fit this 8-bit number into a 3-bit > > storage? > > I think personally I am OK with rejecting requests about this, so we can > agree on this.
It is not possible to reject values passed to set, because it returns Self and follows the builder-pattern, to do this we will need to return Result, and have the caller unwrap it, and have to rename it to try_set(). Instead of that, I would just extract the bits from the value the user passed and ignore the rest (example if 0xff is passed for a 4-bit bitfield, then the field is 0xf.) Alex what do you think, should set_ be fallible? thanks, - Joel
