Add "bitfield" to Cargo.toml keywords

[hecatia-elegua]

This would make it easier to find, I only noticed this existed by reading bitvec docs.
Adding that word in the docs somewhere might help as well, either saying "you can use it like that" or specifying why it is different.

[hecatia-elegua]

I might have misunderstood deku's purpose. Is it really meant for any kind of bitfield?

Comparing asm output of some bitfields implemented in deku vs other bitfield crates, deku produces 20x more code.
This is, with deku = "0.16" using cargo-show-asm.

When looking at cargo expand, I noticed the cause is likely DekuRead and Co. not being const. It would be very interesting to see what happens if it were (nightly) const behind a feature gate.

could open another issue if you want

[wcampbell0x2a]

When looking at cargo expand, I noticed the cause is likely DekuRead and Co. not being const. It would be very interesting to see what happens if it were (nightly) const behind a feature gate.

Could you explain the nightly feature and what this would do? I'm not familiar and curious.

[hecatia-elegua]

@wcampbell0x2a it could call all those trait methods at compile time if possible and/or optimize them out:

see feature const-trait-impl

I'm not sure how #[inline] interacts with this. I'm guessing if the call can't be optimized out at compile time, it inlines. It could also be the case that constness is only relevant to the crate where it is defined.
See the last line here (which I used on some From impls lately):

None: The compiler will decide itself if the function should be inlined. This will depend on factors such as the optimization level and the size of the function. Non-generic functions will never be inlined across crate boundaries unless link-time optimization is used; generic functions might be.

#[inline]: This suggests that the function should be inlined, including across crate boundaries.

Then again, I might have mixed this up (even non-const stuff can get computed at compile time), so if someone wants to go at this, it's probably best to first try to put #[inline] on those trait methods and compare asm outputs.
Edit: I quickly tried adding #[inline] to all the reads and writes in impls::primitives, it didn't inline (and I wouldn't use inline(always)).

[wcampbell0x2a]

fyi: bitvec needs to use heavy usage of inline already to get decent performance: https://github.com/search?q=repo%3Aferrilab%2Fbitvec+inline&type=code