-
Notifications
You must be signed in to change notification settings - Fork 130
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
Add traits for BITS
#271
base: master
Are you sure you want to change the base?
Add traits for BITS
#271
Conversation
What is your use case? Preferably not a hypothetical, or "because we can," but what is a real example where you would like to use generic See also #246 and #247, but those did not provide justification either... This is also different than Also, |
Serializing to and deserializing from bitfields. We didn't use this crate in this PR firecracker-microvm/firecracker#3722 because we needed to get the |
When using big integers as backing storage for cryptographic keys, there are many times it can be helpful to know the bit size of the key. Here are some real-world code examples where we use our own trait for this in @RustCrypto projects. |
Is there a reason you made this a function? This PR proposes
... with |
I do not have a strong opinion about using a constant or function. |
A function might be a bit more helpful, since the size can be determined at runtime: https://github.com/search?q=repo%3ARustCrypto%2FRSA+bits%28%29&type=code FWIW we’re looking at adding a runtime-selected fixed-width integer type to |
That trait predates both
Then that would need to be |
@cuviper yeah, the use cases are similar to In the case of e.g. RSA the standard works around the significant bits vs bit capacity issue by ensuring the two are equal at key generation time, so either definition would work there. |
use core::{u128, u16, u32, u64, u8, usize}; | ||
|
||
/// Numbers which have a specified number of bits. | ||
pub trait Bits { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if you called this trait Precision
instead? Then it could also have bytes()
I assume many of the traits in this crate predate associated constants, but is there any thought to having both trait methods and associated constants? Perhaps in separate traits? (with a blanket impl linking them) Associated constants would be nice for stack-allocated types, and methods for heap-allocated types. |
I think this makes sense (although will likely not be very useful until In this case, these implementations may look like: trait Bits {
fn bits() -> u32;
}
trait ConstBits: Bits {
const BITS: u32;
}
impl Bits for u32 {
fn bits() -> u32 { u32::BITS }
}
impl ConstBits for u32 {
const BITS: u32 = u32::BITS;
} In the future when #[const_trait]
trait Bits {
fn bits() -> u32;
}
impl const Bits for u32 {
fn bits() -> u32 { u32::BITS }
} Presently
e.g. struct Y;
trait MyTrait {
const MY_CONST: usize;
}
impl MyTrait for Y {
const MY_CONST: usize = 4;
}
fn main() {
}
fn blah<T: MyTrait>(x:T) where [();T::MY_CONST]: {
let a = [00u8;T::MY_CONST];
} but adding A lot of potential right now is restricted by:
|
The nice thing about associated constants is they can be used in a |
Was rounding num-rational Ratio to Ratio. This would be nice trait to use in this case. |
Adds a trait for getting the
BITS
constants e.g.u32::BITS
.