num-traits
num-traits copied to clipboard
rust-num
PrimInt: to_be_bytes & co
The current to_be functions require unsafe to get a slice out of them; the individual types now (since 1.32) have to_be_bytes that does not have that flaw.
I suggest adding to_be_bytes() as well as to_ne_bytes and to_le_bytes as well as the analogous from_be_bytes, from_ne_bytes and from_le_bytes.
To implement this, PrimInt would need to get an associated type that reflects such a buffer; depending on when this gets implemented and what MSRV is targeted then, that could be a const NBYTES: usize (where to_be_bytes would return [u8; NBYTES]), or a BytesBuffer associated type with the right array lengths. In the latter form, the associated type would be required by the trait to implement at least TryFrom<&[u8]> and AsRef<&[u8]>.
Researching into whether that latter form would be upgradable to a const generic one easily later, I found that PrimInt is not sealed; that didn't sound too bad until I noticed that even a default implementation that uses to_be() and then transmutes around could still not come up with a suitable sized and owned return value short of returning a Box<[u8]> (that would technically satisfy the bounds but be ugly). Worse yet, it'd slam the door on being able to migrate towards returning [u8; NBYTES] later (which otherwise could be API compatible as the new return type does satisfy all bounds previously placed on it).
Is there any evolution mechanism in num-traits through which to_be_bytes() could be added?
I don't know any way to extend PrimInt for this.
There could be a new trait though -- #103 was working on this, but it would need to be rebased and reviewed again. Someone can also come up with a new design, if they prefer.
Is #103 still the current thinking around it ? If yes, i might want to pick it up and try to resolve pending issues. Related question, if OverflowingShl/Shr implementation like this would also be accepted ?
Is this crate simply abandoned? I need the floating point versions of these (to_bits, from_bits specifically, stabilized in 1.20; bytes stabilized in 1.40: https://github.com/rust-lang/rust/commit/7b72c2831c6a50a9e07a3d94ebef5d9f29bfd51e).
I'm going to just work off of @kaidokert's branch in #224 and make a fork because clearly there's something wrong with maintainership when such an important crate hasn't even allowed workflows to run or even acknowledged #224. I think @kaidokert is far nicer than me, to their credit…and therefore didn't raise this, but I will.
I don't hope to need a fork forever—@hauleth and/or @cuviper need to nominate a new maintainer.
I'm sorry, I will try to get to this, but I have a lot on my plate.
There's also nothing stopping this from being implemented as a separate extension trait, or indeed just using a fork.
No problem, glad to know it's not totally dead :-)
I think you should nominate someone but only you can decide that. I'll maintain a fork for a little while until you're less busy as I need some of the features…