-
Notifications
You must be signed in to change notification settings - Fork 1
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
Create Key
trait
#16
Comments
The issue with the I could add redundant methods like |
Update to trait Key {
fn view_bytes<O, F: FnMut(&[u8]) -> O>(&self, f: F) -> O;
type Inner;
fn as_inner_ref(&self) -> &Self::Inner;
fn from_inner(src: Self::Inner) -> Self;
fn into_inner(self) -> Self::Inner;
} The Another important point is that we cannot implement the Having these additional methods on the trait allows us to input/output values of |
Possibly values for keys:
|
More fleshed-out implementation: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a60b31de91db14fae566069a605be943 The |
Going to hold off on endian types: #[derive(Debug, Clone, Copy)]
#[cfg(feature = "nightly")]
struct BigEndian<T>
where
[(); std::mem::size_of::<T>()]:,
{
_repr_type: std::marker::PhantomData<T>,
bytes: [u8; std::mem::size_of::<T>()],
} Currently crashes my nightly compiler with:
|
Currently the tree only accepts
Box<[u8]>
as keys. I should implement support for different keys types, so long as they can be temporarily transformed to[u8]
of some sort.My initial idea has the general sketch traits:
Example of use for
u64
:See full example at https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0cfdebe7eee884c906ea0607c79e5c07
Ideally I'd like to be able to have the
Key
trait just directly return&[u8]
, not go through a closure, but the issue is that some types need to derive a new value for the bytes, not just expose a reference. For integers, the provided methods (to_le_bytes
, etc) produce an owned array of bytes which doesn't quite work.The uses for the traits:
Key
- this trait is the main one which will be implemented for all keys which can be used with the tree, it allows us to access the component bytes for the type.OrderedKey
- this trait indicates that the lexicographic ordering of the byte-string matches the natural ordering of the type, based on what is used in thePartialOrd
orOrd
implementation.NoPrefixesKey
- this one is the most important for delivering on a non-failinginsert
function. Currently there is only thetry_insert
function, which will fail if the given key is a prefix or makes an existing key a prefix of the new key. This trait would indicate that the set of possible keys will have no prefixes.CStr
)This change would also require changing the overall type variable situation from
<V>
to<K,V>
, and the definition ofLeafNode
would change fromto
The text was updated successfully, but these errors were encountered: