Why follow pointer sizes for BitMemory?

[diondokter]

Hey there,

I'm working on a crate that makes writing embedded device drivers easier.
The main purpose is providing some macros for an easy interface. (example)

For reading the bits, I use this bitvec crate. However, I'd like the user to be able to use the u64 and u128 datatypes if they want.
This is the current way I'm doing this: link
(This turns the backing array into a BitSlice and then uses the BitField trait to store and load the values)

I've been looking through the code and #[cfg(target_pointer_width = "64")] is often used to gate off the u64.
Is there a reason for that? I'm assuming there is and that I'm just not seeing it.

For my need, I'd like bitvec::mem::BitMemory to be always implemented for u64 and u128.
https://github.com/myrrlyn/bitvec/blob/develop/src/mem.rs#L53
That way, the store and load of the BitField will be able to work with it.

Would you be open for a PR that makes that so if it's possible?

[myrrlyn]

I was going to write up an explanation of how this was leftover debris from restructuring the crate, and that I wasn't certain if it would be safe or correct to loosen this restriction, but (a) another person asked a similar question and (b) it actually turns out that all my objections were unfounded.

I have relaxed the BitMemory restriction, but retain the BitStore restriction. Only integers narrower than a processor word can be used as storage regions for bitvec types, but any unsigned integer can be transferred into or out of such a region through BitField.

I am still experimenting with a design for integers wider than a processor word as BitStore units, but since that's not the question you asked, I am assuming that impl BitMemory for u128 is sufficient.

Once the test suite passes, I will push the commit implementing this to GitHub. Please test it on your machine before I publish to <crates.io>. If all goes well, this will be published as 0.18.3, as it is strictly an interface expansion, and modifies no other behavior.

Thank you for this request; I appreciate people pushing the envelope of what I permit.