Summary
Remove our dependency on the byteorder crate and remove the byteorder feature, making the byteorder module available unconditinoally.
Progress
In progress in #583.
Description
Some potential users have expressed concerns over our dependency on the byteorder crate. I have not seen any uses of the types in our byteorder module which mix those types with other uses of the byteorder crate, which implies that we could just define our own ByteOrder trait rather than using the one from the byteorder crate and this wouldn't cause problems for users.
While we're at it, we could use a technique like the following to allow the methods on our types to be const fns:
use core::marker::PhantomData;
pub trait ByteOrder {
#[doc(hidden)]
const ORDER: Order;
}
#[doc(hidden)]
pub enum Order {
BigEndian,
LittleEndian,
}
#[repr(transparent)]
pub struct U64<O>([u8; core::mem::size_of::<u64>()], PhantomData<O>);
impl<O: ByteOrder> U64<O> {
pub const fn new(u: u64) -> U64<O> {
let bytes = match O::ORDER {
Order::BigEndian => u.to_be_bytes(),
Order::LittleEndian => u.to_le_bytes(),
};
U64(bytes, PhantomData)
}
}
Summary
Remove our dependency on the
byteordercrate and remove thebyteorderfeature, making thebyteordermodule available unconditinoally.Progress
In progress in #583.
const fns no longer beconstso that it works with our MSRVconstdepending on Rust version (as prototyped in #574)constDescription
Some potential users have expressed concerns over our dependency on the byteorder crate. I have not seen any uses of the types in our
byteordermodule which mix those types with other uses of the byteorder crate, which implies that we could just define our ownByteOrdertrait rather than using the one from the byteorder crate and this wouldn't cause problems for users.While we're at it, we could use a technique like the following to allow the methods on our types to be
const fns: