Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out multi-bit set/get for bitflags-like usage #19

Open
hecatia-elegua opened this issue May 16, 2023 · 2 comments
Open

Figure out multi-bit set/get for bitflags-like usage #19

hecatia-elegua opened this issue May 16, 2023 · 2 comments

Comments

@hecatia-elegua
Copy link
Owner

Not entirely sure what a good design might look like here.

@dicta
Copy link

dicta commented Jun 26, 2023

I am currently working around this not being implemented yet by converting a uN to its underlying storage representation (u8, u32, etc.), using the trait implementation from bit_field here: BitField, and then repacking the uN.

The linked crate/trait was the most-readable-to-code-using-it API design I had found to date for integrating bitflags-like things into existing numeric types. I don't love its panic behaviour, but otherwise, I'd use it if it integrated with types provided by arbitrary-int.

@hecatia-elegua
Copy link
Owner Author

@dicta Thank you for the info!

I guess I'll think about it now:
I'm inclined to expand sth like

//...
struct Foo {
   field1: u3,
   #[flags(status)]
   field2: bool,
   field3: bool,
   field4: bool,
   field5: u2,
   field6: bool,
}

to all their field getters and setters plus

fn status() -> u3
fn set_status(u3)

and then consts for these three fields (like in bitflags, so you can | them together). We could use BitField too, but I'm trying to avoid user code which looks like set_bit(1), since it won't tell you anything at first glance.

I'm open to bikeshedding and also to just being proven wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants